Re: partially encrypted filesystem

[Pat LaVarre <p.lavarre@ieee.org>]

> 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
linux-scsi.

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

http://fy.chalmers.se/~appro/linux/DVD+RW/
http://fy.chalmers.se/~appro/linux/DVD+RW/#udf

"... 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. 

Ick.

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

Pat LaVarre