Re: partially encrypted filesystem

[Pat LaVarre]

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

Agreed.

> some other method ....
> less likely to cause massive disk fragmentation.

Such as?

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

Pat LaVarre

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/