![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/kernel.png)
|
|
|
 Sections: Main page Security Kernel Distributions On the Desktop Development Commerce Linux in the news Announcements Linux History Letters All in one big page See also: last week's Kernel page. |
Kernel developmentThe current kernel release is still 2.4.2. Linus has resumed work toward 2.4.3; his current prepatch release is 2.4.3pre3. Alan Cox, meanwhile, has kept up his pace and reached 2.4.2ac14. A reader asked us to figure out how much of the "ac" patches have made it into Linus's kernel. Unfortunately, there is no easy answer to that question. Linus's changelogs just say "Alan Cox: continued merging". The only person who actually knows the answer, in all likelihood, is Alan, and he does not have the time to make a list. No new 2.2.19 prepatches have been released in the past week. SnapFS alpha release. Peter Braam and his colleagues at Mountain View Data have announced the alpha release of SnapFS, a new filesystem add-on. As an alpha release, it's not something that you are likely to want to put on that big departmental server. It has some interesting features, though, that make it definitely worth a look. Essentially, SnapFS enables a filesystem to preserve its history. One could compare it to the old VMS file versioning scheme, but SnapFS is far more flexible than that. It can preserve the state of an entire filesystem at any given time; it can also be set up to preserve every revision that is ever made of every file on the system. That latter mode, presumably, is recommended only for users with very large disks. To many, SnapFS may just seem like a way of filling up excess disk space. But, in fact, there are some truly useful applications for such a filesystem:
Whenever a file is to be modified, and its contents must be preserved in a snapshot, SnapFS creates a new inode in the filesystem to hold the snapshot version. An extended attribute which points to the snapshot inode is then attached to the visible version of the file. The actual blocks of the file are shared between the current file and the snapshot until they are changed; at that point the SnapFS "copy on write" mechanism makes copies of the affected blocks. Snapshots are thus relatively efficient in their use of storage, especially in situations where only parts of files are changed. For example, a snapshot of that huge web server log file, which is only appended to, does not duplicate the log entries that are shared between the current and archived versions. This mechanism also makes the creation of snapshots very fast. Since no data is copied at that time, making a snapshot is really just a matter of filling in a table entry. A set of tools is provided with SnapFS to handle the management of SnapFS filesystems, performing rollbacks to older versions, etc. Mountain View Data's revenue model is starting to come into focus, though - a number of additional management tools will be proprietary. For example, there will be utilities to stabilize and quiesce Oracle and MySQL databases for snapshots. The basic SnapFS code, however, is licensed under the GPL. What should the kernel do with DOS-formatted scripts? A user recently turned up a little problem. Imagine that you have a perl script that starts with the usual incantation: #!/usr/bin/perlYou would expect the kernel to be able to run the perl interpreter when the script is invoked. But now imagine that the script is in DOS format - each line ends with a carriage-return and a line feed (\r\n) rather than just a line feed (\n), which has been the Unix standard forever. The kernel, in this case, will see the carriage return as part of the interpreter name; as a result, the user gets a "no such file or directory" complaint from the shell. This user, Ivo Timmermans, included a patch that would make the kernel strip out the carriage return in scripts like this. The initial response from Alan Cox was not particularly receptive: "Fix the script. The kernel expects a specific format." That approach makes sense to some - why should the kernel go out of its way to support scripts that are not in the specified format? It was subsequently pointed out, however, that the kernel will happily strip away other sorts of trailing white space, such as space characters and tabs. Should not carriage returns, which are generally recognized to be white space as well, be stripped too? Good question, with no answer from those who would eventually have to accept the patch. For now, "fix the script" is the order of the day. Other patches and updates released this week include:
Section Editor: Jonathan Corbet |
March 8, 2001
| ||
Copyright © 2001
Eklektix, Inc., all rights reserved![[SnapFS diagram]](/2001/0308/snapfs-diagram.png)
it's restoring files that some user (usually the same user)
destroyed. With snapshots, that process is much easier.
Next: Distributions