[lkml]   [2001]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: writing a plugin for reiserfs compression
Roy Sigurd Karlsbakk wrote:
> > > I just thought there was a patch doing windows nt-like
> > > compress-em-all-realtime-and-get-doomed!
> >
> > I don't know what the actual heuristics for determining which files are
> > compression with the ext2 patch. It is definitely NOT a compressed
> > block device. Files are compressed in chunks (32kB?), so that it is
> > possible to seek and do read-modify-write (e.g. appending to a file)
> > without decompressing the entire file and/or recompressing it. This also
> > protects against block corruption, since you would limit the amount of
> > data lost to the end of the chunk after the bad spot.
> But still... Are the files are compressed as they are created/modified on
> the filesystem? My main point was to avoid the compression overhead and
> just decompress the file at access time if it's compressed. Compression
> should (IMO) be done nightly.
> Perhaps a file should be decompressed when it's modified and either (a)
> set scheduled to next nightly compression or (b) stay uncompressed the
> next <n> days. I mean - as a file is being modified, the chance is large
> that the file will be accessed pretty soon...
> > Yes, definitely disabling compression for a file is good. The "accessed
> > in last 7 days flag" is questionable. This could be determined via the
> > atime on Unix and doesn't need a separate flag. Also, the difference
> > between "do not compress" and "can't compress" is very small. If it is
> > found that the file is incompressible, you could just as easily set the
> > "do not compress" flag.
> I agree on the 'accessed in last <n> days'. It'd be better to check atime.
> I'd still like to separate 'do not compress' and 'can't compress', as to
> show why the falg has been set - the former is set by the admin and the
> latter by the system.
> roy

I think you'll find it easiest to code it such that doing anything to the file
body, reading or writing, decompresses it. Fancier stuff can wait for later

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:12    [W:0.058 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site