lkml.org 
[lkml]   [2000]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4 Features
Hi Peter.

>>> The only 'backwards compatibility' code that I'm interested in
>>> seeing in the kernel would be code that decompresses depreciated
>>> compression

> Well, I've never quite got what the problem really is. One wants
> to decompress under a kernel that supports 0.3 and compress
> again under a kernel that supports 0.4. If 0.4 grows a 0.3
> decompression routine, then that's the best of all worlds. But
> does one need the kernels for this?

Actually, there's no problem with 0.3 against 0.4 as 0.3 won't be
going into any standard kernels anyway. I'm working strictly with the
0.4 version.

The basic point is this: If, as a result of experience after the
e2comp subsystem is folded into the kernel, the decision is taken to
depreciate a particular compression method, MY opinion is that the
CORRECT way to do so is as follows:

1. Remove the compression side thereof, and tweak the kernel to
declare any files compressed with it as being read-only until
such time as they are converted to a fully supported compression
format. The kernel would also at this stage be set to log a
message stating that file X is compressed with the said
depreciated protocol and should be converted before the kernel
is updated.

Note that in this context, a request to rename or delete the
file would NOT be considered to be a write request.

2. Tweak the e2fsck tool to look for any files compressed using a
depreciated protocol and perform the equivalent of doing the
following on all such files:

chattr -c '{}' && chattr +c '{}'

This should result in all such files being converted to a
non-depreciated protocol fairly soon after the decision was
made to depreciate the given protocol.

Since such a tweak should be generic enough to automatically
determine which compression protocols are currently set up as
depreciated and uncompressable, and should ignore files that
are not uncompressable, this will require either a sysctl or
an extra file in /proc to provide the relevant details.

3. Wait for several (at least 8) kernel versions to be released.

4. Remove the decompression side as well, and tweak the kernel to
refuse all access to the said file, with the kernel logging a
message stating that access was refused, and why.

I still believe such to be the correct way of doing so, but I am open
to comments as to what is wrong with it.

>> I wouldn't even do that much. Take the code out of the kernel
>> entirely, and then provide a user-mode utility that goes through
>> the filesystem, and converts the files compressed with a
>> depcreated algorithm to either being uncompressed or compressed
>> with a better format. The goal here is to keep the kernel as
>> long-term maintainable as possible.

If you read the above, you will see that the long term aim of such a
decision would indeed be to take it out of the kernel entirely, but
the design provides for automatic conversion

> Can this be done in user space? ... e2fsck does things at that
> level! It's just playing on the raw device.

Given the above procedure for depreciating a compression protocol,
there should be no need for a separate user-mode protocol to do that.

> Peter Moulder has lately folded together the 0.3 and 0.4 e2compr
> utilities, I believe. I had mail from him over new year. Do
> these now get around the problem of needing one kernel to
> decompress with and another to compress with? How far off a
> userspace solution are we?

I'm dealing strictly with the 0.4 version, so will leave comments
regarding this to Peter...

Best wishes from Riley.

* Copyright (C) 1999, Memory Alpha Systems.
* All rights and wrongs reserved.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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