In article <AMOSS.93Jul28133119@picton.cs.huji.ac.il> amoss@picton.cs.huji.ac.il (Amos Shapira) writes:
quoted text
>rohrer@fncrd6.fnal.gov (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"...

quoted text
>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.
Maybe one bit per block, though this would make updating in the middle of
the file REALLY crazy...still, if the compression method brings a good reason
to do so, how can a Linux be feebler than v.42bis, which was designed by
committee?

And what's DOS-ish about it?  The "To be compressed, or not to be compressed" 
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).

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

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

quoted text
>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.
How the heck, without kernel support at least, do you expect to get
control of a read request?

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