Cc: <linux-kernel@...>, Peter Zijlstra <a.p.zijlstra@...>, Nick Piggin <nickpiggin@...>, Paul Jackson <pj@...>, Dave Chinner <dgc@...>, Andi Kleen <ak@...>
On Thursday 19 April 2007 19:35:04 Christoph Lameter wrote:
(ramfs).
general
mm
layers).
Hello,
This is exactly what I wanted some time ago,
Thank you very much, I was almost thinking of doing this myself
(but decided that it is too difficult now for me and maybe doesn't worth the
effort)
I want to point out on number of problems that this will solve (and reasons I
wanted to do that)
First of all, today, packet writing on cd/dvd doesn't work well, it is very
slow because
now all file-systems are limited to 4k-barrier and cd/dvd can write only
32k/64k packets.
This is why a pktcdvd was written and it emulates those 4k sectors by doing
read/modify/write cycle
This cause a lot of seeks and read/writing switches and thus it is very slow.
By introducing a bigger that 4k page cache a dvd/cd can be divided is 64k/32k
blocks that will be read an written freely
(Although dvd can read 2k I don't think that reading a 64k block will hurt
since most of time drive is busy seeking and locating a specific sector)
Now I thinking to implement this in an other way, I mean I want to teach udf
filesystem to to packet writing on its own, bypassing disk cache (but not page
cache)
Secondary 32/64k limitation is present of flash devices too, so they can
benefit too, and I almost sure that future hard disks will use bigger block
size too.
To summarize I want to tell that bigger pagesize will allow devices that have
big hardware sectors to work fine in linux.
Best regards,
Maxim Levitsky
-
