linux-kernel - Re: What's in libata-dev.git

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <20060911202300.GD10409@kernel.dk>
Date:	Mon, 11 Sep 2006 22:23:00 +0200
From:	Jens Axboe <axboe@...nel.dk>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Sergei Shtylyov <sshtylyov@...mvista.com>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...l.org>,
	Linus Torvalds <torvalds@...l.org>
Subject: Re: What's in libata-dev.git

On Mon, Sep 11 2006, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Mon, Sep 11 2006, Jeff Garzik wrote:
> >>Jens Axboe wrote:
> >>>On Mon, Sep 11 2006, Alan Cox wrote:
> >>>>We could perhaps do it by ATA version - 255 for ATA < 3 256 for ATA 3+,
> >>>Might be sane, yep.
> >>
> >>Since we're doing this just for paranoia, and nobody can actually 
> >>produce a problem case, it's safer just to hardcode 255 for all cases, 
> >>than try to come up with a hueristic that won't be exercised for another 
> >>decade...
> >
> >If it's a real problem, yes I agree. If it's just hand waving, then no.
> >The fact that 2.4 and 2.6 has been using 256 for ages really tells me
> >that no one has been affected by this. The SUSE bugzilla certainly
> >hasn't seen any entries on it either.
> >
> >>Most new disks are lba48 anyway.  (should we use 65535 there too???)
> >
> >Heh, good question. Given that the limit is so high, we might as well
> >just use 65535. It's not nearly as sensitive as the lba28 case.
> 
> Well, I _do_ think it's just hand waving, but OTOH I don't see much harm 
> in using 255.  Contiguous 256-sector reads and writes have gotta be 
> pretty rare.  But that's just a hand-waving guess too ;-)

Just check the default read-ahead size - it's 256 sectors. It's really
not that rare. The read-ahead case can be made a little more clever (and
it really should be), but still. I did some numbers on this when I wrote
the fcache code, and just a regular boot does generate some really big
requests. Big writes are trivial.

248 sector contig requests will in reality be just as fast as 256, I'm
more concerned about the alignment aspect of it. ATA does hit platter
speed fairly quickly. When I last measured a few months ago, for
sequential reads you are already there at 16 sectors (again rounded to
actual observed io in real life, raw it was around 6KiB). The really
nasty case is cache set to write through, there you really want every
milimeter of extra io size to get the performance up on writes.

-- 
Jens Axboe

-
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/