[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1003142216380.15263@asgard.lang.hm>
Date: Sun, 14 Mar 2010 22:20:42 -0700 (PDT)
From: david@...g.hm
To: Denys Vlasenko <vda.linux@...glemail.com>
cc: "H. Peter Anvin" <hpa@...or.com>, Arnd Bergmann <arnd@...db.de>,
Tejun Heo <tj@...nel.org>,
"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
Daniel Taylor <Daniel.Taylor@....com>,
Jeff Garzik <jeff@...zik.org>, Mark Lord <kernel@...savvy.com>,
tytso@....edu, hirofumi@...l.parknet.co.jp,
Andrew Morton <akpm@...ux-foundation.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>, irtiger@...il.com,
Matthew Wilcox <matthew@....cx>, aschnell@...e.de,
knikanth@...e.de, jdelvare@...e.de
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
cycle)
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists