Leisner.Henr@xerox.com (marty) (10/04/89)
I think imposing a file system switch and insisting users tar-out + tar-in is sinful. The kernel switch a la V8 is a good idea and should be simple enough. The code could be duplicate in the few utilities which read raw disks, or 2 versions of these utilities could exist (maybe under /usr/old/bin) and let the user know what he's doing. It would take far fewer man-hours to have 2 way compability than insist all Minix users switch formats [which message did this talk of a new filesystem start in? I must have missed it]. marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: leisner:wbst139:xerox UUCP: hplabs!arisia!leisner
root@cca.ucsf.edu (Systems Staff) (10/05/89)
In article <24987@louie.udel.EDU>, Leisner.Henr@xerox.com (marty) writes: > I think imposing a file system switch and insisting users tar-out + tar-in > is sinful. > > The kernel switch a la V8 is a good idea and should be simple enough. I find it hard to believe that someone as knowledgeable as Marty could have posted this. Trading a one time minor task for a kludge that would complicate the logic of a critical element of the system and would add confusion, overhead, and bug-proneness for the long term isn't sensible. Look, a tar-out + a tar-in is a one time operation and you are going to do the tar-out (or equivalent) anyway, right? You really wouldn't consider bringing up a new system version without backing up your disk would you? Would you? OK, so you're going to to do the back up so you have to have and handle all those disks anyway and the only extra is reading them back in. Now if you put in that switch, you're going to have all this data which is incompatible with assorted programs that expect all the data in the i-node to be correct. But you can't even simulate this because you only have the one date in the i-nodes on the old filesystem. Maybe there are other missing fields that would cause problems; I didn't bother looking -- one is enough. Thos Sumner Internet: thos@cca.ucsf.edu (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos BITNET: thos@ucsfcca U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA I hear nothing in life is certain but death and taxes -- and they're working on death. #include <disclaimer.std>
root@cca.ucsf.edu (Systems Staff) (10/05/89)
In article <24987@louie.udel.EDU>, Leisner.Henr@xerox.com (marty) writes: > I think imposing a file system switch and insisting users tar-out + tar-in > is sinful. > > The kernel switch a la V8 is a good idea and should be simple enough. I find it hard to believe that someone as knowledgeable as Marty could have written this. Putting in a kludge like dual file-system formats just to avoid a simple one time operation is not sensible. Remember, you are going to back up your disk before you install the new system anyway, aren't you? Aren't you? Fine, so you have to have and handle all these disks, identify your valuable data, organize your backups logically, etc. That's the hard part. All you could save is reading the data back in. Pretty small potatoes. And what would you have to swallow to save this? Well, the handling of a critical element of the system would get more complicated and bug-prone as well as having extra overhead. And this would go on and on and .. Not only that, but you would create inescapable bugs. Any program which expected to see a correct response to a stat call would be vulnerable because you can't treat the date_time information correctly. You just can't correctly simulate the behaviour of three time entries with only one. And no Posix conformance ... Thos Sumner Internet: thos@cca.ucsf.edu (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos BITNET: thos@ucsfcca U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA I hear nothing in life is certain but death and taxes -- and they're working on death. #include <disclaimer.std>
henry@utzoo.uucp (Henry Spencer) (10/06/89)
In article <2453@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Systems Staff) writes: >> The kernel switch a la V8 is a good idea and should be simple enough. > >I find it hard to believe that someone as knowledgeable as Marty >could have posted this. Trading a one time minor task for a kludge >that would complicate the logic of a critical element of the system >and would add confusion, overhead, and bug-proneness for the long >term isn't sensible. Filesystem switches have many uses other than filesystem conversions. And that "one time minor task" is one-time and minor only if it works perfectly the first time. Ask people about their 4.1BSD->4.2BSD conversions. -- Nature is blind; Man is merely | Henry Spencer at U of Toronto Zoology shortsighted (and improving). | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
root@cca.ucsf.edu (Systems Staff) (10/06/89)
In article <1989Oct5.181148.8229@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <2453@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Systems Staff) writes: > >Trading a one time minor task for a kludge > >that would complicate the logic of a critical element of the system > >and would add confusion, overhead, and bug-proneness for the long > >term isn't sensible. > > Filesystem switches have many uses other than filesystem conversions. Yes, but usually only on research or other special purpose systems (in this context we are only talking about filesystems for the same device population -- not like the differences due to mixed read/write and read-only media). A major goal of Minix is clarity and building in such unnecessary complication goes against that goal. Not to mention the problem of the user level incompatibilites which would be introduced (which your comments did not address) ... > And that "one time minor task" is one-time and minor only if it works > perfectly the first time. Well, I do make the simplifying assumption that you aren't going to reload your personal files until you have the new system running. That seems to be a reasonable assumption. So do the implicit assumptions that you are already familiar with your hardware and its reliability so you know whether you need multiple copies of your backups etc. and that you aren't so careless as not to label and write-protect your backup media. And then there are the possibilities of doing the conversion in situ or between separate areas (for those who have the space) on the hard disk avoiding the need to restore from backup media in the normal case. > Ask people about their 4.1BSD->4.2BSD conversions. I don't have to ask; I went through it. Likening reloading files on a personal system to dealing with the typically hundreds of megabytes belonging to hundreds of users on such systems and trying to make the changeover transparent to them is not appropriate for evaluating the former. Henry, thanks for your ever perspicuous comments. Thos Thos Sumner Internet: thos@cca.ucsf.edu (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos BITNET: thos@ucsfcca U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA I hear nothing in life is certain but death and taxes -- and they're working on death. #include <disclaimer.std>
ast@cs.vu.nl (Andy Tanenbaum) (10/06/89)
In article <1989Oct5.181148.8229@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Filesystem switches have many uses other than filesystem conversions. >And that "one time minor task" is one-time and minor only if it works >perfectly the first time. My hope is that things will be reasonably tested out before the definitive posting. At first I thought this was not a practical idea, but I have had some second thoughts. What I intend to do is to have an in-core inode structure that is reasonably decoupled from the bits on the disk. For example, in the incore inode structure, a disk address will be 32 bits, even though on the disk it is only 24 bits. This doesn't allow larger disks, but if makes dealing with disk addresses easier. The real reason for decoupling, however, is to make the IBM and Atari disks exactly the same (little endian). On an Atari, one would read in an inode, fumble with it a little, and get a proper in-core inode structure with the same 32-bit addresses as on the PC. I think that only 6 routines would be needed: read and convert an inode deconvert and write an inode read and convert a bit map deconvert and write a bit map read and convert a superblock deconvert and write a superblock I don't think these routines will be more than a page or two. Anyway, when the time comes, I'll look at it. Does anybody object to having the PC and Atari disks be medium compatible? Andy Tanenbaum (ast@cs.vu.nl)
henry@utzoo.uucp (Henry Spencer) (10/07/89)
In article <2461@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Systems Staff) writes: >> Filesystem switches have many uses other than filesystem conversions. > >Yes, but usually only on research or other special purpose systems Um, you obviously aren't acquainted with some of the things that can be done with them. (And you've forgotten that teaching -- Minix's raison d'etre -- is very definitely such a "special purpose".) >(in this context we are only talking about filesystems for the same >device population -- not like the differences due to mixed read/write >and read-only media). Even if you restrict it to the same device population, there is much to be said for being able to optimize different filesystem for things like speed vs. space. More to the point, though, the big win of filesystem switches is being able to make filesystems out of things that *don't* "really" look like filesystems. Disks in highly nonstandard formats (like MSDOS or TOS). Network connections with file servers on the other end. The process table in the system ("/proc" is superior to "ptrace" in every way). User programs that present services that want to look like files. >Not to mention the problem of the user level incompatibilites which >would be introduced (which your comments did not address) ... Uh, *what* user level incompatibilities? There is no reason for user programs to see any change whatsoever, except having more facilities available. -- Nature is blind; Man is merely | Henry Spencer at U of Toronto Zoology shortsighted (and improving). | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
root@cca.ucsf.edu (Systems Staff) (10/07/89)
In article <1989Oct6.170630.6287@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <2461@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Systems Staff) writes: [Off the point of the present case (dual filesystem formats for Minix 2.0) material deleted.] > >Not to mention the problem of the user level incompatibilites which > >would be introduced (which your comments did not address) ... > > Uh, *what* user level incompatibilities? There is no reason for user > programs to see any change whatsoever, except having more facilities > available. Well, if you read my first posting in this thread you will see an example for the case which is really in question. I think this thread is worn out. Most of what is being said is not relevant to the issue in hand. Thos Sumner Internet: thos@cca.ucsf.edu (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos BITNET: thos@ucsfcca U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA I hear nothing in life is certain but death and taxes -- and they're working on death. #include <disclaimer.std>
rbthomas@athos.rutgers.edu (Rick Thomas) (10/07/89)
> From: ast@cs.vu.nl (Andy Tanenbaum) > The real reason for decoupling, however, is to make the IBM and Atari > disks exactly the same (little endian). On an Atari, one would read in > an inode, fumble with it a little, and get a proper in-core inode structure > with the same 32-bit addresses as on the PC. I think that only 6 routines > would be needed: > read and convert an inode > deconvert and write an inode > read and convert a bit map > deconvert and write a bit map > read and convert a superblock > deconvert and write a superblock > > I don't think these routines will be more than a page or two. Also, those routines could be used -- line for line, probably -- in the applications programs (like fsck and mkfs) that need to know about physical file system formats. Thus finessing (most of) the problem of having lots of commands that have to be rewritten to accommodate file-system-switch. Adding new file-system types then becomes a trivial task of relinking with an updated library. (-; Well, actually it depends a lot on how bizarre the new files system type is, but you get the idea... Some of Henry's suggestions sounded pretty bizarre, even to me. Can you imagine what would happen if you did "fsck /dev/proc" ? ;-) (It would be nifty to be able to access a DOS disk from Minix via regular Minix commands, as Henry suggested. No need for dosread/write/dir ever again!) (Of course, if this discussion is starting to sound familiar to you, all of it has been said before with regards to BTL Research's V8 UNIX.) Rick -- Rick Thomas uucp: {ames, att, harvard}!rutgers!jove.rutgers.edu!rbthomas internet: rbthomas@JOVE.RUTGERS.EDU bitnet: rbthomas@zodiac.bitnet Phone: (201) 932-4301
steve@basser.oz (Stephen Russell) (10/07/89)
One argument not yet discussed for supporting both file systems is the desire to maintain compatibility with existing media. Andy's "backup/ switch FS/restore" scenario is acceptable if _everything_ is on the HD. Many users though may have dozens of floppies which will become obsolete if no backward compatability is provided. Sure, they can be converted if someone writes a conversion utility, but it's a slow process. Incompatible file systems also make exchanging disks with other Minix users difficult. As we've seen with the 1.1->1.2->1.3->1.4 upgrade path, the users won't all be running the same system at any one time. I'd still like to be able to have a friend send me a Minix disk without having to worry what version she's running. (Yes, I know they could send me a raw disk, but ...) As Andy has mentioned, converting the disk format to an internal "canonical" format may not be very difficult, and may have advantages for PC & ST compatibility (and other future Minix systems?). IMHO, Andy should investigate this option further. If it turns out to be a clean change, then why not do it that way? Of course, many mistakes have been prolonged beyond their natural life in the name of "backward compatibility" :-)
ncoverby@ndsuvax.UUCP (Glen Overby) (10/08/89)
In article <2454@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Systems Staff) writes: >In article <24987@louie.udel.EDU>, Leisner.Henr@xerox.com (marty) writes: [personal slurs deleted] >> The kernel switch a la V8 is a good idea and should be simple enough. >Putting in a kludge like dual file-system formats just to avoid a simple >one time operation is not sensible. I think having a filesystem switch would be nice. As it stands right now, the only way I can touch my DOS partitions is with "dos{read,write,dir}'. If multiple mounted filesystem formats were supported, then I could MOUNT them (after writing an MS-DOS filesystem, of course -- and no, that is not an impossible task). And how about remote filesystems? Do you say the same about the people at Sun who designed NFS that you did about Marty? One of my former (now graduated) office mates put something like this into Minix for his MS thesis. His main goal was to be able to mount another machine's disk over a network; he didn't have the network so he just worked on the split in FS to mount another <something> filesystem. I never saw it running, but I got the impression that it still needs a lot of polishing. He had FS communicating with another process that handled the other filesystem formats. Simplicity and luxury will always be opposites. -- Glen Overby <ncoverby@plains.nodak.edu> uunet!ndsuvax!ncoverby (UUCP) ncoverby@ndsuvax (Bitnet)
henry@utzoo.uucp (Henry Spencer) (10/08/89)
In article <3544@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >... What I intend to do is to have an in-core inode >structure that is reasonably decoupled from the bits on the disk... >The real reason for decoupling, however, is to make the IBM and Atari >disks exactly the same (little endian)... This sounds like an excellent idea. The transition from pdp11s to VAXen was made unnecessarily difficult by byte-order problems with the file systems, which could have been avoided quite easily by such a method. (In fact, I recall a talk about "8.2BSD", which was 2.8BSD that some group had hacked to use VAX byte order in its filesystems, so they could swap disks around easily.) >... I think that only 6 routines would be needed... Sounds plausible to me. I second the suggestion that these routines be made available (in a library?) to fsck and friends too. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
peter@ficc.uu.net (Peter da Silva) (10/08/89)
File system switches are quite useful. On the Amiga this sort of capability
is provided by what's called a "handler", which effectively does its own file
system parsing on a filename, making whatever is inside it look like a file
system. Here are some of the alternative systems:
The standard file system.
The Fast File System, a version of the standard file system
that has less redundancy to improve speed.
RAM: an automatically sized RAM disk, which allocates memory for
files on the fly.
VD0: like RAM:, but it survives a reboot. A bonus that comes with
ASDG's RAM cards.
VDK: similar to VD0:, but a normal commercial product.
NET: A networked file system.
CrossDOS, a file system that lets you transparently read and write
MS-DOS disks. A commercial product.
Also, there are file-system-like things:
CON: Console window interface. The path specifies the size, title, and
position of the window.
PATH: A modified RAM disk that allows you to create directories that
point to a set of directories elsewehere in the system. For
example, if you set up PATH:C containing the lines "RAD:C",
"RAM:C", "DF0:C", and "Workbench:C"... if you tried to open
"PATH:foo/copy" it would look for copy in all the directories
names.
PIPE: A named pipe device. If you open PIPE:foo for reading, and
another program opens it for writing, you can talk to each
other.
A raw disk interface, I don't know the name or syntax.
All of these things really add to the hacker-friendliness of the machine. I
would recommend a file system switch to anyone.
--
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
'U`
Quote: Structured Programming is a discipline -- not a straitjacket.