And when every app does understand compression, you won't have to worry
about which FS you're trying to do compression on, it'll work on ext2,
minix, (u)msdos, NFS, etc... It's not a ext2fs world out there
unfortunately.
linux kernel account <linker@nightshade.ml.org> writes:
> How about maintaining a buffer of space and uncompressing files in use..
Where, on disk? Why bother compressing, and what if it doesn't fit?
Miquel van Smoorenburg <miquels@cistron.nl> writes:
> I've though about this a couple of times, and I think it's not that
> hard. You just divide each file into chunks of (say) 4Kb. You then
> compress that 4Kb block. If it becomes 1Kb, great, you put it in the
> first block of 4, and the other 3 blocks are empty. Since empty
> blocks do not take up disk space (holes), that's no problem.
>
> So you don't compress the file as a whole, you compress it on a 4Kb or
> 8Kb block basis.
How do you compress the blocks? Compress 4K real bytes per block or
compress until you get a 4K block? Either way how do you tell which block
has what data in it without sequentially reading the whold damn thing. This
method would require some kind of indexing scheme to be at all effecient,
which I suppose is not really a problem if you're doing it at the FS layer,
but you're increasing overhead considerably for usually relatively poor
compression.
Now, solve this one, you open the file read/write and you start changing
the file in random places. Since even changing one byte will change the
compression dynamics you end up re-compressing/re-writing everything
following the position at the write(), block compression or no... I
challenge you to code that efficiently.
- Steve
.------------------------------------------------. # * # # # # # #
| Steve Baker | Barely Working | # ## # # # # #
| ice@mama.indstate.edu | System Administrator | # # # # # # # #
| Red-Hat Rulz! | Will work for hardware | # # # ## # # # #
`-- SYS-ADMIN FOR HIRE, HAVE UNIX, WILL TRAVEL --' #### # # # ## # #