Finding the best filesystem (for USB flash drive installs)

[pizzar0]

Finally a good investigative start! Good job.
Those numbers look familiar. (Let me guess: current Kingston <16GB USB/controller? Although you could've just told us...

... and here it is, in your own words - assuming that you used Parted > ver. 0.6 or sfdisk/fdisk > ver. 2.17 but Not cfdisk:

maybe there are a certain number of sectors at the beginning of the partition that push the actual data out of alignment?

Yes, there are. -And Yes, "aligned" means what the built-in micro-controller decides it means, not what Parted says - although ver. >0.6 goes some way to fixing that.

ON AVERAGE(!!), running the same/similar tests as you've just completed, on 15-20 top-selling USB drives currently on the market, one will find that the "deterioration" of XFS' performance due to bad NAND chips, messed-up controllers, etc. is significantly less - more fault tolerant, or "compensatory" - then that of EXT4. In some, quite common, instances those performance differences, which you have observed, simply go off the charts. (Read Penalty -> EXT4 vs. XFS >200% in favor of XFS.)
Of course, there remains XFS' bias in working with large(r) files. (Its data-recovery potential still remains without peers!) Compare that to EXT4's preference to not work at all (for all practical purposes) in the case of many, currently available USB drives.

[Ahau]

Thanks -- you're confirming my fears (namely, that USB controllers are all over the board, and there really is no one best filesystem for use with all USB flash drives).

Yes, I should have specified, this is my 8 GB Kingston DT101 G2.

Here's the log for how I set up the offset partition for ext2:

Code: Select all

bash-4.1# fdisk /dev/sdb 

Command (m for help): p

Disk /dev/sdb: 7998 MB, 7998537728 bytes
128 heads, 32 sectors/track, 3814 cylinders, total 15622144 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5a5a5a5a

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        8192     4095999     2043904   83  Linux
/dev/sdb2         4096000    15622143     5763072   83  Linux

Command (m for help): d
Partition number (1-4): 2

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4, default 2): 2
First sector (2048-15622143, default 2048): 4096063
Last sector, +sectors or +size{K,M,G} (4096063-15622143, default 15622143): 
Using default value 15622143

Command (m for help): p

Disk /dev/sdb: 7998 MB, 7998537728 bytes
128 heads, 32 sectors/track, 3814 cylinders, total 15622144 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5a5a5a5a

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        8192     4095999     2043904   83  Linux
/dev/sdb2         4096063    15622143     5763040+  83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.
bash-4.1# partprobe
bash-4.1# fdisk /dev/sdb

Command (m for help): p

Disk /dev/sdb: 7998 MB, 7998537728 bytes
128 heads, 32 sectors/track, 3814 cylinders, total 15622144 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5a5a5a5a

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        8192     4095999     2043904   83  Linux
/dev/sdb2         4096063    15622143     5763040+  83  Linux

Command (m for help): w   
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.
bash-4.1# 
bash-4.1# mkfs.ext2 /dev/sdb2 
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
360448 inodes, 1440760 blocks
72038 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1476395008
44 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 20 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
bash-4.1# 

This was using fdisk from util-linux 2.19 (x86_64 -- default for V1.0 Porteus 64 bit edition). I previously set the geometry to 128 heads / 32 sectors per track using cfdisk (fdisk seems to be buggy when it comes to setting the geometry). I've been setting my partitions to start on an even multiple of 8192 sectors--however, it sounds like some FS's (e.g. FAT32) will use an uneven number of sectors at the start of the partition (not the drive) for the FAT table and some unallocated space, before the first datablock. Thus, aligning your partition to an even sector might not actually line up your data blocks with the NAND pages... reference: http://www.patriotmemory.com/forums/sho ... ning-FAT32

When I create an EXT partition, it tells me that the first data block is block 0, which I assume to mean that the first block in the partition lines up with the first sector of the partition on the disk; but I don't know that for sure. XFS doesn't really give me an indication:

bash-4.1# mkfs.xfs -f /dev/sdb2
meta-data=/dev/sdb2 isize=256 agcount=4, agsize=360190 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=1440760, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
bash-4.1#

BTW, if you like the data I presented above...I have lots (and lots) more data where that came from

[pizzar0]

Yes, that data has practical relevance, although mostly only in the case of Kingston.
But may all not be lost...

Here is something(s) may be worth to ponder;

According to Zsolt Kerekes (He runs probably the most trusted developer/enterprise SSD tech. portals on the web.)

You don't need to understand semiconductor physics to buy a new processor or a server - but at this particular generation in the evolution of the SSD market we're in today - you do have to be aware of a heck of a lot of technology and architectural concepts if you want to successfully leverage SSD technology in large scale deployments. Eventually that will change. But it could take another 3 years.

The above said, and true as all that is,... Sandisk modeled its new PRO 2000 Enterprise series with the dm_raid (main line) driver (Linear RAID) and xfs. THEN they translated the whole combo into silicon and BAAAM!! - came out with their 2000 PRO series drives, the fastest SDD drives in history and 2x faster than their nearest competitor. (550 MB/s r/w. encrypted by default.) Probably the simplest of all designs, even according to Sandisk. Beautiful!
So, it is somewhat telling what can be achieved with the correct use and combination of tools, even if they are only emulated in software. (Which is how one gets >300 out of a $60 stick.)
One can not help but to wonder; What if someone threw together an optimized FS+controller combo that probably would work for ~80% of the USB sticks out there (more less) and then dropped that into a "module"...
(just wondering...)

[tome]

An another option is Universal Disk Format (UDF). The biggest advantage of this log-structured and open vendor-neutral file system is POSIX (Linux) compatibility and Windows, Mac OS X read/write ability. UDF formatted drive can be used for porteus changes=EXIT: cheatcode, unfortunately plain changes= doesn't work (maybe aufs mounted read-only bug and after such try filesystem becomes readonly under Windows), additionally some special files like symlinks created under Linux (e.g. by changes=EXIT:) could not be deleted under Windows. Only few boot loaders recognize this format (grub4dos can't read it). After installing GRUB2 on partition-less UDF drive, fdisk sees partition (before there was no one), some BIOSes can't boot from unpartitioned drives so for this partition can be set bootable flag to omit such issue. UUID can't be set for partition-less (superfloppy) UDF disks but it is possible to set UUID in fdisk if "fake" partition was created by grub2 (required some tests). Another disadvantage is missing fsck tool and in some cases disk may be full even if the system shows there is available space (log-structured fs behavior like f2fs ?, required confirmation).
To format as UDF, udftools package is needed.
Comparison of FAT32 and UDF:: https://j0nam1el.wordpress.com/2015/02/ ... -with-udf/
How to format: http://superuser.com/questions/39942/us ... lash-drive
Script to format in UDF: https://github.com/JElchison/format-udf (requires vim package - xxd command, or comment all lines with xxd in script)
Wikipedia: Universal Disk Format

LAST EDIT: 2016.09.04