lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 14 Mar 2010 22:20:42 -0700 (PDT)
To:	Denys Vlasenko <>
cc:	"H. Peter Anvin" <>, Arnd Bergmann <>,
	Tejun Heo <>,
	"" <>,
	lkml <>,
	Daniel Taylor <>,
	Jeff Garzik <>, Mark Lord <>,,,
	Andrew Morton <>,
	Alan Cox <>,,
	Matthew Wilcox <>,,,
Subject: Re: ATA 4 KiB sector issues.

On Mon, 15 Mar 2010, Denys Vlasenko wrote:

> On Monday 15 March 2010 02:21, H. Peter Anvin wrote:
>> On 03/10/2010 01:14 AM, Denys Vlasenko wrote:
>>> 63s/255h is more or less "standard" now.
>>> Alignment issues can be solved by picking a good multiple of
>>> _heads_ or _cylinders_:
>>> For first partition, pick the start at 8th head:
>>> cyl 0 head 1 sector 1: LBA sector 63) - bad
>>> cyl 0 head 8 sector 1: LBA sector 8*63) - good (4k aligned)
>>> For any other partition, pick start cylinder which is a multiple of 8:
>>> cyl 8*x head 0 sector 1: LBA sector 8*x*255*63 - good (4k aligned)
>>> This will actually work well for *any* geometry, not only for 63s/255h.
>> Yes, but it does squat for a flash disk that wants, say, 256K alignment.
> 4K makes sense. 256K not so much.
> 256K alignment is hard to swallow for a lot of reasons anyway.
> Unless the filesystem packs small files into blocks a-la reiserfs,
> 256K block filesystems will be very inefficient for a typical
> storage scenarios.

the thing is, if the OS can learn that it's more efficiant to write in 
256K aligned chunks, then it can batch up things so that the drive doesn't 
have to do a read-modify-write cycle and can instead just replace the 
entire chunk.

raid arrays can benifit from this as well as SSDs.

the OS can do this when writing things to swap, flushing dirty buffers, 
mmaped files, etc (in fact, if the OS knows the full contents of the 
chunk, it may be more efficiant for the OS to write the entire thing then 
to write part of it and have the drive/array do the read-modify-write 

David Lang

> It looks like flash storage manufacturers just have to bite
> the bullet and develop smarter algorithms that combine wear
> leveling, block remapping and such and make their internal
> preference for huge continuous aligned writes nearly invisible
> from the outside - just like hard disks which do not expose
> their zoned recording, variable sector counts etc.
> Such algorithms aren't trivial, but they are possible.
> Whoever will incorporate them in their products,
> delivers a significantly better user experience.
> I just played with ubuntu installation on an usb stick.
> Yes, it works. Soft of. Write performance is abysmal.
> I would pay x2 or x3 for the same sized stick if it
> would perform better.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists