From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264156AbTDKEI6 (for ); Fri, 11 Apr 2003 00:08:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264157AbTDKEI6 (for ); Fri, 11 Apr 2003 00:08:58 -0400 Received: from h80ad2608.async.vt.edu ([128.173.38.8]:54145 "EHLO turing-police.cc.vt.edu") by vger.kernel.org with ESMTP id S264156AbTDKEI4 (for ); Fri, 11 Apr 2003 00:08:56 -0400 Message-Id: <200304110419.h3B4JeBm004315@turing-police.cc.vt.edu> X-Mailer: exmh version 2.6.3 04/02/2003 with nmh-1.0.4+dev To: Shaya Potter Cc: John Bradford , Alan Cox , root@chaos.analogic.com, Frank Davis , Linux Kernel Mailing List Subject: Re: kernel support for non-english user messages In-Reply-To: Your message of "Thu, 10 Apr 2003 18:20:15 EDT." <1050013215.23204.8.camel@zaphod> From: Valdis.Kletnieks@vt.edu References: <200304102036.h3AKa837025670@81-2-122-30.bradfords.org.uk> <1050013215.23204.8.camel@zaphod> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1967715762P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 11 Apr 2003 00:19:40 -0400 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org --==_Exmh_1967715762P Content-Type: text/plain; charset=us-ascii On Thu, 10 Apr 2003 18:20:15 EDT, Shaya Potter said: > On Thu, 2003-04-10 at 16:36, John Bradford wrote: > > > There is a lot of anti-VMS stuff in the Unix world mostly coming > > > from the _horrible_ command line and other bad early memories. There > > > is also a hell of a lot of really cool stuff under that command line > > > we could and should learn from. > > > > When are we going to see versioned filesystems in Linux? That was a > > standard feature in VMS. > > it shouldn't be that hard, it was one of the 6 OS projects for the > regular 4000 level (senior/grad) level OS class here at columbia last > semster. > > The assignment was to modify ext2 to support versioning, basically means > making a copy of it within ext2's open, if it's opened O_RDWR. The > assignment was a little bit more complicated in that we took an ext2 > flag bit to mean "version", so that a file would only be versioned if > the bit was set, as well as only allowing a single level of versioning, > though extending it w/ more wouldn't be that hard. > > The student solutions (as well as our sample solution) weren't that > "pretty", but then again, each project was only for 2-2.5 weeks. The problem is, as usual, in the details that almost never get handled in 2-week student projects. Some off the top of my head: 1) What happens when *multiple* programs have a file open at the same time? If you only handle one level of versioning, somebody is going to lose. Handling multiple levels is of course more "fun". And you get to worry about race conditions - does your code DTRT if multiple processes do an open() on alternate CPUs at the same time. Does it DTRT if a process open()s a file, and then fork()s, and both parent and child start scribbling on the file descriptor? 2) For that matter, should new versions be created at open() or at the first write()? Doing it at write() allows not creating a new version if no changes have actually happened - but this has its own issues. 3) Version a 500 megabyte file. Change one block. Do it a few more times. Are you better off copying the whole file (which bloats your disk usage and kills your I/O bandwidth), or keeping deltas (the list of allocated blocks could be almost identical except for the replaced/rewritten blocks). However, this DOES make doing an fsck() a *lot* more interesting - is a block allocated to multiple files in error or not? 4) What happens if you rename() a file? Can you open() a previous version for writing? If so, does it get versioned? How does a backup program restore a previous version? 5) Let's say we use VMS-style filenames to version. foo, foo;2, foo;3, etc. Now, is open("foo;2",...) a reference to the previous version of foo or to a new file that happens to be called foo;2? What happens if some other file happens to be called foo;2 and you create a version of foo? 6) OK, since anything besides \0 and / is legal in a filename, we can't use ;N to version. Let's steal another field in the inode to do the counting. Now how does userspace reference a previous version easily? Can you get into a situation where different versions of a file have different owners/permissions? 7) Userspace support. Anybody want to open that can and take up worm farming? ;) 8) User support issues. See (7). ;) That's just the first 10 minutes or so of thinking about things that could be problems that a student project won't address. Yes, VMS had to worry about a lot of these issues too - but VMS had the advantage that versioning was designed into the environment from very early on, and wasn't a retrofit as it would be for Linux. So they could make arbitrary rules like "If there's a ;nnn on the end of a filename, it's a version" without having to worry about breaking anything. --==_Exmh_1967715762P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE+lkJbcC3lWbTT17ARAt+kAKCShYN2tkJ0zP/e4a5r3tT6+CmMOgCfTZZi lqjtcweUD7ps6LE82maasMw= =PToa -----END PGP SIGNATURE----- --==_Exmh_1967715762P--