Re: why umsdos?

Matthew Wilcox (Matthew.Wilcox@genedata.com)
Mon, 9 Nov 1998 10:50:14 +0100


On Sun, Nov 08, 1998 at 11:13:14PM -0500, Anthony Barbachan wrote:
>
> -----Original Message-----
> From: Matthew Wilcox <Matthew.Wilcox@genedata.com>
> To: Anthony Barbachan <barbacha@Hinako.AMBusiness.com>; Matthew Wilcox
> <Matthew.Wilcox@genedata.com>; linux-kernel@vger.rutgers.edu
> <linux-kernel@vger.rutgers.edu>
> Cc: humbubba@raptor.cqi.com <humbubba@raptor.cqi.com>
> Date: Sunday, November 08, 1998 4:53 PM
> Subject: Re: why umsdos?
>
>
> >On Sun, Nov 08, 1998 at 03:31:21PM -0500, Anthony Barbachan wrote:
> >> 1. Increases risk to wipeing out the Linux system exponentially as by
> >> deletely one file accidently (the image file) on the DOS system would
> wipe
> >> out the Linux system.
> >
> >Use ATTRIB under DOS to deal with this problem. And of course, your system
> >wouldn't be recoverable to the average newbie user (which is what his
> system
> >is designed for) if one were to delete (eg) C:\LINUX\LIB\LIBC.SO.
> >
>
> What about his data? And whatever attributes you set with the attrib
> command can be easily overridden.

Of course they can be overridden, but you used the word `accidentally'.
ATTRIB stops it being an accidental deletion and makes it a
yes-i-really-know-what-i'm-doing deletion. I have no idea what you mean
by `What about his data?'

> >> 2. No speed improvement, most likely there would be a speed decrease.
> >> file system request -> UMSDOS -> FATFS -> drive
> >> vs.
> >> file system request -> EXT2 -> loop device driver -> FATFS ->
> drive
> >
> >Show me the numbers, I'm not convinced.
> >
>
> Your adding another layer to the I/O flow and you expect a speed up???

Yes, since it's not quite as black and white as you paint it. It does
of course depend on exactly which operation you're doing, but the only
operation which is required on the FAT fs when using a loop device is
the bmap() method, which ought to be fast, I can see that it might well
be faster to use ext2 than a kludge around (finding an acceptable short
name for a file, storing the long name into a different file, putting the
permissions in that file too, working out equivalent DOS attributes, ...)

> >> 3. No gain in feature except perhaps the cluster space problem on large
> >> drives (Not applicable if UMSDOS now works on FAT32 as I have hear)
> >
> >you then don't need UMSDOS. And you don't need to write UNTFS.
> >
>
> For the network I would definately need it, if I want access to a unix-like
> file system. What if I needed to lock a file? I can't lock the entire
> image if others are using it.

Ah, this is a good point. I can't think of a good work around for that.

> >I don't think this is a problem if someone's evaluating Linux. If they
> >want to do more than evaluate Linux then they should partition anyway.
>
> UMSDOS isn't necesarily only being used by newbees. It can be an excellent
> choice for a dual OS system. No need to reformat a hard drive (no need to
> buy a resizing repartitioner either), easily share data betweem systems, one
> can even use commercial disk repair tools (of which non that I knwo of
> exists for linux yet), etc.

The `easily share data between systems' is bogus, since you can mount
your DOS partition under Linux anyway. What do `commercial disk repair
tools' do that e2fsck does not? I'm sure tytso would like to know.

-- 
Matthew Wilcox <willy@bofh.ai>
"I decry the current tendency to seek patents on algorithms.  There are
better ways to earn a living than to prevent other people from making use of
one's contributions to computer science."  -- Donald E. Knuth, TAoCP vol 3

- 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/