[lkml]   [2003]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: partially encrypted filesystem
> Even if you were going to admit to having a block size of 64KiB to the
> layers above you,

Within pdt x05 dvd/ cd, as contrasted with pdt x00 hdd/ flash, since
1999 we have an ansi t10 paper standard for a device to report bytes per
write block inequal to bytes per read block i.e. the 1999 mmc x0020
RandomWritable "feature" that describes a disc in a drive.

I haven't yet seen an fs run in Linux that bothers to fetch this plug 'n
play data, hence my op x46 GPCMD_GET_CONFIGURATION patches of

> you just can't _do_ atomic replacement of blocks,
> which is required for normal file systems to operate correctly.

Google tells me cd-rw and dvd+rw likewise do not support random writing
without load balancing e.g.

"... As you might know DVD+RW media can sustain only around 1000
overwrites. The thing about fully fledged file systems is that every
read [or tight bunch of 'em] is accompanied by corresponding i-node
update or in other words a write! ..."

> These characteristics of flash have often been dealt with by
> implementing a 'translation layer' -- a kind of pseudo-filesystem --
> which pretends to be a block device with the normal 512-byte
> atomic-overwrite behaviour. You then use a traditional file system on
> top of that emulated block device.


Naive read-modify-write to raise bytes-per-write-block passed-thru drops
thruput like 7X in the benchmarks I've seen.

Pat LaVarre

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

 \ /
  Last update: 2005-03-22 13:59    [W:0.118 / U:4.808 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site