Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: partially encrypted filesystem | From | Pat LaVarre <> | Date | 09 Dec 2003 16:40:54 -0700 |
| |
> 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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |