[Solved] Flash Drive 128k Alignment

Beeblebrox · #1 August 3rd, 2012, 20:14

For those who are not aware: USB flash drives have slow data write speed, but it's because most flash drives have 128k erase block size, while filesystems usually have 4k block size. This means that filesystem blocks are not aligned to flash drive blocks, resulting in overhead during disk writes (I'll leave it up to you to do the full read).

Usually the partition made at the factory sets everything as it should be, but if you have deleted the original partition table, then you will be in a bit of a mess because the partition tools (like gpart or fdisk on linux) will not align the newly created partitions correctly.

From what I have read, for proper alignment of filesystem: One should use 224 heads (32*7) and 56 sectors (8*7) per track to get 12544 (256*49) sectors per cylinder. Results in cylinder size of 49*128k.

If you have a new MBR table on the flash drive or if you placed a freebsd-boot partition (usually between 36k-64k in size) at the start of your GPT partitioned drive, then you must align the first useable partition to 128k for optimal write speed. Normally I would choose GPT partition, but Win XP cannot mount GPT. The assumption for flash drives (specially USB) is that they usually need to be mountable by all O/S.

If you intend the flash drive to be non-booting and can use it as GPT, then you might falsely think that placing a partition starting at zero will solve this. Unfortunately while the "initial alignment" issue will be correct, sectorsize will not: It will show 512 instead of the desired 128.

OK, enough of the background description. Now for the problem:
Create MBR table, add partition with 128k offset from zero and show results:
# gpart create -s mbr da0
# gpart add -b 65 -t linux-data /dev/da0

Code:

63  3946953  da0  MBR  (1.9G)
63       63       - free -  (31k)
126  3946887    1  linux-data  (1.9G)

Great! We seem to have the correct offset needed for fast-write. Unfortunately that's half the problem. The other half is sectorsize, and I can't get gpart nor linux's fdisk to set 128k sectorsize! 512 will not (afaik) optimize the write speed.

Code:

# diskinfo -v /dev/da0
	512         	# sectorsize
	2020872192  	# mediasize in bytes (1.9G)
	3947016     	# mediasize in sectors
	0           	# stripesize
	0           	# stripeoffset
	245         	# Cylinders according to firmware.
	255         	# Heads according to firmware.
	63          	# Sectors according to firmware.

The questions are:
1. Is there anything wrong in my description?
2. If not, how can I set 128k partition size?
BTW, this problem is valid for USB's and all SD cards (cameras, phones, etc.)

**wblock@** · #2 August 3rd, 2012, 20:28

Drive sector size is hardware and can't be changed. However, with some filesystems you can control the size of reads and writes. See http://ivoras.net/blog/tree/2011-01-...or-drives.html for a UFS example. There are options with MS-DOS, too: newfs_msdos(8) although I don't know which to suggest. Change one at a time and benchmark.

Beeblebrox · #3 August 3rd, 2012, 20:40

This whole exercise on my part aims to align partition to hardware setup anyway.

Quote:

Drive sector size is hardware and can't be changed

In that case I would not insist on 128, but would go with whatever the hardware dictates.
How can I check and be sure of hardware sectorsize?

**wblock@** · #4 August 3rd, 2012, 20:58

Unless the manufacturer documents it somewhere else (most don't), you have to go by what the drive says. Or a larger multiple of that.

xibo · #5 August 3rd, 2012, 22:14

FFS stores data in blocks that are divided into fragments if the driver considers this useful (e.g. large block size and storing small files). Each such fragment has 1/8 of the partition's blocksize.
By default, FFS uses 32k sized blocks which results in 4k sized fragments. While I don't know whether fragment modification causes read+rewrites of the whole block or only the sectors that are mapped for those fragments, setting the filesystem blocksize large enough will automatically increase the disk write/read lengths.

Beeblebrox · #6 August 15th, 2012, 00:58

@xibo: The problem is with overlap of "erase blocks" and "drive blocks". Although admittedly I am not 100% sure I understood all details in your post.

For those who are interested, this is what started the whole ball rolling for me: http://wiki.laptop.org/go/How_to_Dam...Storage_Device

My solution: Usually I have a single partition on my USB's. I also make them bootable (for rescue tools and booting iso's) and they manage to boot things through grub. Not elegant, but I started the USB partition at 0 (zero), and flash drive speed increased. Normally grub would want a separate partition labeled boot-bios, but I did not create one. The result is a not-suggested grub method of using blocklists on the main partition. So be it and that's what I went with. Another solution would be to place the boot-bios (if you use GPT) at the end of the USB.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Mounting USB Flash Drive	kind	Peripheral Hardware	9	December 19th, 2011 01:14
flash drive install help	Huckey	Mobile Computing	5	April 25th, 2011 11:36
Unable to read tape after writing with 128k blocksize	gschadow	Peripheral Hardware	1	March 4th, 2010 16:32
[Solved] USB flash drive woes	Eponasoft	Peripheral Hardware	22	January 22nd, 2010 01:30
Installing on a USB Flash drive?	diskman	Installing & Upgrading	4	January 4th, 2010 17:18