user filesystems 1802

as the original troll, I don't want to take much more time here. it would be nice, though, if there were also some more single-end-user oriented filesystems, perhaps giving up performance for features. feel free to ignore the rest.

* compression and encryption indeed would go nicely hand in hand. yes, compression can be faster, too. for backups, an rsync to an auto-compress filesystem would save a lot of space without sacrificing convenience. I am not sure I would want it on my ordinary file system. maybe yes, maybe no. (stacker was a big mistake, because basic meta-data corruption could kill the entire parbreastion contents.) yes, hard drives are cheap. backup hard drives could store more rsync copies, though. I do not believe there is a geom-like module on linux that allows compression-encryption transparently.

* versioning would be nice; yes, it is a subsbreastute for backup, backup, backup. Incidentally, your editor most likely creates versions already using the ~ suffix; its just not supported by the filesystem.

* undelete---if it is a security risk, perhaps we could allow the filesystem to turn it off, too. A "move to trashcan" is not the same thing. One needs to compress it to gain more space again. I do not know ext3 or other internals---how does it determine which blocks are now empty? keeping one linked list where the oldest blocks are preferentially used for the next block write request would probably hit performance, but allow relatively painless undeletes.

none of these is absolutely necessary. we can all live without it. again, my point is that it would be nice to have some more plain end-user oriented filesystems, too.

regards,iaw