Subject: Re: Undelete for linux? From: amoss@picton.cs.huji.ac.il (Amos Shapira) Date: 29 Jul 1993 15:06:56
rohrer@fncrd6.fnal.gov (Keith Rohrer) writes:
|(Amos Shapira) writes:
|>(Keith Rohrer) writes:
|> I saw that in the documentation for ext2, probably the 0.3 version; I for
|> one would really love to see a defragger before compression even comes into
|> play. Preferably one that syncs at the right times--unless there's already
|> a way to tell the buffer cache "Hey, I'm doing large block transfers, if
|> you don't deal with this, the drive is going to start spending 99% of its
|> time doing silly seeks...".
|>There is a defragger for IRIX efs, for instance, they just run it once a week
|>during the weekend. This isn't DOS you know :).
|This is my PC we're talking about; it gets no "weekend"...
What I was saying is that defragging once a week seems to be enough on a system
I know. You don't have to play games with TSR-like programmes which pull the
disk under the OS' feet :). It doesn't have to be during the weekend either.
|>Also I have no idea how ext2fs does what it does but the biggest impruvment
|>in BSD 4.2 which gave it its place in the holl of fame was the special Fast
|>File System which was smart enough to move blocks around as the files grew
|>and shrunk and plan the block allocation according to heauristics which
|>prevent fragmantation altogether, we could run our VAX 750 for years without
|>having to defrag the disks and with mean fragmantaion of less than 3%.
|> Compression would be good, too, especially if
|> it were fast, especially if it were enabled and disabled based on names?
|> Like, say anything .gz, .tgz, .lha, .lzh, .zoo, .zip, &c, doesn't get
|> compressed, anything .txt does... Specifying compression by directory
|> and by name (incl. wildcard match) will be vital, imho. It might be good to
|> have a this-file-does-not-compress-well bit the fs could set, too...
|>You seem to think in DOS terms again. So far I supposed people were talking
|>about compression in the kernel level, which means the kernel deals with
|I am talking about compression in the kernel level, at the file level--though
|the possibility of having one inode's blocks compressed and another inode's
|blocks uncompressed, for the same file, is either intriguing or highly insane.
I suspect you are mixing things here. Every file has exectly one, and only
one, inode. What I ment in my previous sentence is that having the kernel
decide about compression based on the file name seems unlikely to me.
|And what's DOS-ish about it? The "To be compressed, or not to be compressed"
I ment "DOS-ish" to the way you think problems should be solved. In DOS,
from the little I've seen, problems are "solved" by brute-force hacking into
or around the "OS" while in UNIX elegancy, integrity and compatibility are
the main theme.
|choice can be made when the file is first created; subsequent links will
|just point to that file, whatever its representation on the disk may be.
|The kernel can have the wildcards and paths hardcoded, or they can be set
|manually (my extreme preference is for the latter, of course).
|>i-nodes not with file names. What if a file have two hard links, one with
|>".tgz" and one with ".txt"? I don't see such a scheme becoming a reality and
|The first name it was created under would be matched against the criteria
|in force at the time, and it would be created compressed or non-compressed
|according to that. From there, if links were created, or a rename occurred,
|it would still be compressed (or not) and there would be no excuse to change
|it. Also, if user intervention causes the file to be uncompressed, compressed,
|or marked/cleared as compression-hostile, what the user did sticks.
^^^^^^ you
probebly ment "stinks".
Ever heard of Chris Torek? He's one of the old chaps from the good old
comp.unix.wizards days and he once said (please correct me if I dis-attribute
this) that UNIX doesn't prevent users from doing stupid things with the
computer because it will also stop them from doing smart things with it.
And to your suggestion - what if the user tries to "mmap" the file? Will the
system uncompress the file and give him a new page? What if he changes this
page? Will the system recompress the entire file? Will the system just turn
off the compression on that file?
|>if it does then I would reconsider using Linux as it will head stright on the
|>path of behemoth like VM, VMS, NOS-BE etc. were the kernel does EVERYTHING for
|>you whether you like it or not.
|If you don't want compression, either don't compile it in, or turn it off.
I agree. Only what I'm saying is that the nice thing about UNIX is that it
(used to be?) lean and mean. And people keep adding too many features to it.
I won't prosecute anyone who adds this feature but it is possible to solve the
same problems without it, IMHO.
|>People keep forgeting one of the basic blocks of the UNIX phylosophy: if
|>you can do it outside the kernel then don't put it in.
|I'd love to see completely installable filesystem and device drivers under
|Linux, where a 'user' program can run the 'system-level' details of managing
|a filesystem, where a hacker can use his video memory for a 3/4 Mo ramdisk,
|loading it when he needs it and unloading it before something else needs
|the video memory. Alas, this isn't Mach, nor is it Plan 9; live with it.
Fine. But would you do this also at the price of breaking compatebility
and elegancy of generic code? Would you give up or redefine this kind of
feature if they required changing code which has nothing to do with them?
|How the heck, without kernel support at least, do you expect to get
|control of a read request?
I don't. In DOS you have to overcome a source-less useless OS to do neat
things like adding such features, but not in UNIX.
Keith
--
Disclaimer: None of Grinnell College, URA, Fermilab, and any other affiliated
persons or orginizations have licensed my ideas or opinions, and thus are
not entitled to any which may appear above.
GCS d* -p+ c+++ l++ m* s/* g+ w++ t++ r++ x/--
--Amos