Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
Just adding a few instances here. If someone is interested they can use these to update the pandorawiki SD card list. I don't have the time or interest to figure out how to update it. This specific card did not have an entry.
I had requested this to be done several times in other threads about the Lexar 128GB card. Rather than necroposting those threads, I started a new one.
Since I was re-arranging partitions and card usage and had the opportunity to - I ran these.
Read benchmarks were done using: dd if=/dev/mmcblk0 of=/dev/null bs=4MiB count=100
Write benchmarks were done using: dd if=/dev/zero of=/dev/mmcblk0 bs=4MiB count=100
Warning - that write benchmark IS DESTRUCTIVE. Don't do it unless you are willing/able to re-partition your card and start over.
Benchmarks were run 3 times each.
Card: Lexar Professional 128GB SDXC Class 10 133x
Obtained from: http://www.bhphotovideo.com/c/product/756124-REG/Lexar_LSD128CRBNA133_128GB_Professional_133x_SDXC.html
Left slot Read benchmark: 17.2MB/s 17.2MB/s 17.2MB/s
Left slot Write benchmark: 11.1MB/s 11.8MB/s 11.8MB/s
Right slot Read benchmark: 17.2MB/s 17.2MB/s 17.2MB/s
Right slot Write benchmark: 11.8MB/s 11.8MB/s 11.9MB/s
The following work fine (three 3MB partitions made with cfdisk used for testing):
mkfs.ext2 -L one /dev/mmcblk0p1
mkfs.ext3 -L two /dev/mmcblk0p2
gparted did not like my partitions two above - so I asked it to format them as ext3 and created a third fat32 partition respectively. gparted generated an error as if it didn't work - but the next screen showed the partitions as I would expect them to look. I'm putting this part up as a weirdness in gparted for now.
Checking them in cfdisk/mmcblk0 resulted in something other than expected for the ext3 parition - so I umounted /dev/mmcblk0p2 and re-formatted it again with the mkfs.ext3 as above.
Through that mess my cfdisk /dev/mmkblk0 now looks like:
mmcblk0p1 Primary Linux ext2 [one] 3000.01
mmcblk0p2 Primary Linux ext3 [two] 3000.01
mmcblk0p3 Primary W95 FAT32 3000.01
Pri/Log Free Space 123035.62
So - formatting them worked in the end, though the gparted tool seems to have issues with creating ext3 partitions on the Pandora - though it works fine for creating fat32.
moving on...
# umount /dev/mmcblk0p1
# fsck /dev/mmcblk0p1
fsck from util-linux-ng 2.17
e2fsck 1.41.9 (22-Aug-2009)
The filesystem size (according to the superblock) is 1220702 blocks
The physical size of the device is 732422 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? n
However - if I re-format the same partition again and instead run:
# e2fsck -p /dev/mmcblk0p1
I get:
one: clean. 11/183264 files. 12586/732422 blocks
So I tried to make it fail by running:
# e2fsck -fp /dev/mmcblk0p1
I get:
one: 11/183264 files (0.0% non-contiguous), 12586/732422 blocks
OK - so that seems fine. There seems to be a disconnect between what e2fsck does when called directly and what fsck does (despite it seemingly calling e2fsck). No idea.
Moving on...
# e2fsck -fp /dev/mmcblk0p2
I get:
two: 11/183264 files (0.0% non-contiguous), 28987/732424 blocks
I can't run fsck on 3 because it's fat32.
# dosfsck /dev/mmcblk0p3
I get:
Seek to -1294959104:Invalid argument
No idea...
All 3 partitions read/write data fine.
There seem to be some big inconsistencies in how different partitioning (cfdisk and gparted) and formatting (mkfs and gparted) and file system analysis (fsck, e2fsck, dosfsck) work on the Pandora.
This may help explain why one person will have rotten luck getting ext3 running on an SD card - and another person has no issues (gparted vs cfdisk). There is no consistent standard for measurement of what constitutes a 'failure' on the SD card compatibility list. In some cases this may be a failure in the utility being used rather than the card? Maybe.
Thank you.
I had requested this to be done several times in other threads about the Lexar 128GB card. Rather than necroposting those threads, I started a new one.
Since I was re-arranging partitions and card usage and had the opportunity to - I ran these.
Read benchmarks were done using: dd if=/dev/mmcblk0 of=/dev/null bs=4MiB count=100
Write benchmarks were done using: dd if=/dev/zero of=/dev/mmcblk0 bs=4MiB count=100
Warning - that write benchmark IS DESTRUCTIVE. Don't do it unless you are willing/able to re-partition your card and start over.
Benchmarks were run 3 times each.
Card: Lexar Professional 128GB SDXC Class 10 133x
Obtained from: http://www.bhphotovideo.com/c/product/756124-REG/Lexar_LSD128CRBNA133_128GB_Professional_133x_SDXC.html
Left slot Read benchmark: 17.2MB/s 17.2MB/s 17.2MB/s
Left slot Write benchmark: 11.1MB/s 11.8MB/s 11.8MB/s
Right slot Read benchmark: 17.2MB/s 17.2MB/s 17.2MB/s
Right slot Write benchmark: 11.8MB/s 11.8MB/s 11.9MB/s
The following work fine (three 3MB partitions made with cfdisk used for testing):
mkfs.ext2 -L one /dev/mmcblk0p1
mkfs.ext3 -L two /dev/mmcblk0p2
gparted did not like my partitions two above - so I asked it to format them as ext3 and created a third fat32 partition respectively. gparted generated an error as if it didn't work - but the next screen showed the partitions as I would expect them to look. I'm putting this part up as a weirdness in gparted for now.
Checking them in cfdisk/mmcblk0 resulted in something other than expected for the ext3 parition - so I umounted /dev/mmcblk0p2 and re-formatted it again with the mkfs.ext3 as above.
Through that mess my cfdisk /dev/mmkblk0 now looks like:
mmcblk0p1 Primary Linux ext2 [one] 3000.01
mmcblk0p2 Primary Linux ext3 [two] 3000.01
mmcblk0p3 Primary W95 FAT32 3000.01
Pri/Log Free Space 123035.62
So - formatting them worked in the end, though the gparted tool seems to have issues with creating ext3 partitions on the Pandora - though it works fine for creating fat32.
moving on...
# umount /dev/mmcblk0p1
# fsck /dev/mmcblk0p1
fsck from util-linux-ng 2.17
e2fsck 1.41.9 (22-Aug-2009)
The filesystem size (according to the superblock) is 1220702 blocks
The physical size of the device is 732422 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? n
However - if I re-format the same partition again and instead run:
# e2fsck -p /dev/mmcblk0p1
I get:
one: clean. 11/183264 files. 12586/732422 blocks
So I tried to make it fail by running:
# e2fsck -fp /dev/mmcblk0p1
I get:
one: 11/183264 files (0.0% non-contiguous), 12586/732422 blocks
OK - so that seems fine. There seems to be a disconnect between what e2fsck does when called directly and what fsck does (despite it seemingly calling e2fsck). No idea.
Moving on...
# e2fsck -fp /dev/mmcblk0p2
I get:
two: 11/183264 files (0.0% non-contiguous), 28987/732424 blocks
I can't run fsck on 3 because it's fat32.
# dosfsck /dev/mmcblk0p3
I get:
Seek to -1294959104:Invalid argument
No idea...
All 3 partitions read/write data fine.
There seem to be some big inconsistencies in how different partitioning (cfdisk and gparted) and formatting (mkfs and gparted) and file system analysis (fsck, e2fsck, dosfsck) work on the Pandora.
This may help explain why one person will have rotten luck getting ext3 running on an SD card - and another person has no issues (gparted vs cfdisk). There is no consistent standard for measurement of what constitutes a 'failure' on the SD card compatibility list. In some cases this may be a failure in the utility being used rather than the card? Maybe.
Thank you.