Re: partially encrypted filesystem
From: Pat LaVarre
Date: Sat Dec 06 2003 - 15:13:55 EST
> > Suppose we wish to encrypt the files on a
> > disc or disk or drive that we carry from one
> > computer to another.
> > Where else can the encryption go, if not
> > "down to the file system"?
> From: ...maze...
> ... sparse feature... of the filesystem ...
> ways for which it likely wasn't designed,
> thus ... likely ... problems ... slowdowns ...
> sparse .... seldom used ... mostly ... static ...
> later write access ... better or worse .... fragmentations ...
> may ... required ... significant ... making ... work _well_
> some other method ....
> less likely to cause massive disk fragmentation.
> From: ...valdis...
> ... Other ... theoretically ... if not totally workable.
Aye personally I focus on workable application of theory.
> above ... a la PGP ...
Aye I see "compressed folders" arriving on desktops, and I see
commercial encryption using that same approach.
> below ... a la encrypted loopback ....
I'm guessing encryption raises many/all the same issues as compression.
Frustratingly, I find I can't quite lay hold of why people haven't more
widely adopted compression/ encryption in random-access storage.
Personally I mostly ignored storage until 1994, then I dug in, then I
felt most shocked to discover nothing like modem compression deployed,
not even compression for each concentric track of an HDD. Conceptually
I like e.g. Usenix talk re garbage-collected log-structured
filesystems, but nobody's made those real, I'm not yet clear why.
I want compression to trade away time for space, to mess with the
phenomenon of people living all life at 95% of quota, and to contradict
the theory that no fs works well when more than 50% full.
P.S. Maybe my second deepest culture shock was finding max bytes/cdb
choked off near zero e.g. 64 KiB in many places, 128 KiB now rumoured
for parts of lk 2.6. I'm not sure how often quantitative measurements
of algorithms wrongly show no improvement because swamped by that limit.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/