http://lifehacker.com/5837769/make-s...ve-performance

To see if your partitions are aligned correctly, hit the Start menu and type in

Code:

msinfo32

. Enter Msinfo32 and go to Components > Storage > Disks. Look for your SSD on the list and find the "Partition Starting Offset" item. If this number is divisible by 4096 (that is, if dividing it by 4096 equals a whole number and not a decimal), your partition is correctly aligned.

I am looking for the same thing in Linux.

Are you supposed to align your USB flash drives to 4096 bytes as well as SSDs? Some of mine are aligned, some don't, strangely. Is there a detailed step by step guide to do that?

Hi,

You can do a LQ search for 'SSD alignment' and get loads of helpful threads/posts.

One of many that should help;
https://www.linuxquestions.org/quest...sd-4175414207/

I doubt you'd find much improvement. USB flash drives tend to be a collection of weird stuff going on inside. Not sure I'd ever attempt to fool with them. They may mount like a scsi but aren't internally a true drive. Maybe CF or SD flash may be more ISO like.

1 members found this post helpful.

For SSDs, you want to avoid layouts that would have an erase block, which might be 256KB, that spans more than one filesystem. It's not for performance reasons, but for data integrity. You want to avoid operations in one filesystem causing part of another filesystem to be copied and reallocated. That's why modern partitioning tools default to 1-Megabyte alignment for partitions.

"Are you supposed to align your USB flash drives to 4096 "

No, I have never heard of it.

1 members found this post helpful.

Thanks, but I did not ask for SSD alignment.

Besides, this thread is definitely not the definitive one regarding usefulness even if one looks for SSD alignment.

I am sorry I have no idea what do you mean by 256 kb and 1 Mb alignments. Perhaps a link to a definitive article would be helpful.

All I heard is the 4096 byte alignments - http://en.wikipedia.org/wiki/Advanced_Format

---------- Post added 08-18-13 at 09:01 AM ----------

To back to my original question - anyone has a solution for this?

Hi,
There are links within the referenced links to help you. You did say "as well such as SSDs". Rather broken sentence but you did refer to 'SSD'. At least that is what I got from the title.

See post #5

There is a hardware issue with usb flash drives. They are not all the same. They were never intended to replicate a hard drive. They may have some very odd coding in them to match odd memory chips or odd controllers. Don't bother to align them. You won't find any benefit.

You are welcome to try some of the already posted links to ways one might do it for a ssd. Do this only on a test usb flash. It may not work on all of them and may even bork the drive.

I'll just offer this quote from the Red Hat Solid State Disk Deployment Guidelines:

"Because of the internal layout and operation of SSDs, it is best to partition devices on an internal erase block boundary. Partitioning utilities in Red Hat Enterprise Linux 6 chooses sane defaults if the SSD exports topology information.

"However, if the device does not export topology information, Red Hat recommends that the first partition be created at a 1MB boundary."

For information about erase block sizes, I suggest any of the Google hits on "ssd erase block".

Thanks for your feedbacks. I'll look into the links.

About USB sticks were never intended to replace HDDs? They have come a long time, definitely. Think about USB3 sticks, certified to run Windows 8 from it. Along the same thinking, they would just run a Linux even faster than Windows.

-

OK, and anyone knows the answer to the 1st part of my Original Post? That would be more interesting or important than all we are talking about here. Thank you.

Fdisk uses this default too, I cannot even override it, so I guess it is a non-issue...

So it is the TRIM command in plain English? (First result in the search link) As it is default in modern operating systems, at least in Windows 7.

You seem to lack an understanding of how the flash memory used in flash drives and SSDs works. You cannot write ONEs to flash memory cells. You can only write ZEROs. Only by erasing an entire block can its cells be changed back to ONEs. The erase blocks are large, typically 256KB, 512KB, or even larger in newer, higher density devices. Your OS, on the other hand, will read and write data in sector-size units of 512 or 4096 bytes. When the flash memory controller sees a write that would update part of a block that is currently in use, it reads the entire block, reallocates that block to a new, currently erased block, and writes out the entire block including the modifications. The old block is then marked "free", and will be erased to all ONEs at some future time. Unless you are happy with having writes to one filesystem possibly causing part of a different filesystem to be reallocated and copied, it is undesirable to have an erase block that spans more than one filesystem.

Erasing a block is a relatively slow operation, so for efficiency the controller needs to maintain a pool of blocks that are in the erased state. The TRIM command is a way for the OS to tell the flash controller that the data in a block is no longer needed and the block can be marked "free." But the TRIM command is actually of fairly minor importance in modern drives. The flash device actually contains significantly more blocks than its advertised capacity, so there is always a pool of blocks not currently in use. In fact, enabling automatic TRIM can seriously hurt performance. Prior to SATA 3.1, TRIM was defined as a non-queueable command, so using the "discard" (automatic TRIM) option can cause slow write performance. Scheduling a once-a-day fstrim operation a a cron job might be preferable.

1 members found this post helpful.

I suggest that you test a usb flash using some performance suite in linux. Do this before and after you align it. Then post the results.

OK, and actually anyone has anything to say about my original REAL question? If you say "I have no idea" that's OK to me, I stop quoting myself again and again.