[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.022 / U:38.136 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site