>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?'
>
If you delete a file system image the entire system is deleted. If you
accidently delete one file it is just that file is lost. While they would
probably not be able to start up the Linux system unless they replace the
lost C library their data would still be around and could be retreived. And
attrib makes it a yes-I-know-... only in a DOS prompt. If the user is using
Windows the confirmation could have already have been turned off for file
deletions, the deletion of directories is a separate option. And I have
seen more than enougth users say 'Y' without reading what the prompt had
said, so they could still easily accidently delete a file system image. To
delete a directory they would have to use the deltree command which is less
likely.
>> >> 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, ...)
>
There is another possible slow downer for a file system image. The FAT fs
would have to loop through each cluster to get to whatever ext2 data portion
was requested even if that portion was nearer to the end of the file. Even
if the image were to be unfragmented the FAT fs wouldn't be able to assume
this because it would be a dangerous assumtion. Which means that while a
request to a UMSDOS stored file would be able to directly go to the area of
the disk where that file is stored (after the disk address is read from the
FAT), an image file would have the FAT fs looping through FAT entries in
oder to find the area of the disk to go to. Keep in mind that disk I/O is
slower than CPU processing which may mean that whatever extra processing the
UMSDOS fs does is still faster than the file system image seeks.
>> >> 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.
>
I was thinking of the other way around, easily accessing data when in DOS or
Windows. Its nice to be able to use commercial repair tools, they still
have features that aren't yet readily available if available at all on
Linux. Some use intensive disk sector testers to detect sectors that are
near failure, this has helped me find the cause of some problems on
DOS/Windows machines (windows dies with various problems if the swap file
happens to use one of those "weak" sectors). There's also the undo
capability of some of the commercial disk repairers. The disk defragmenters
which optimize the files depending on their usage are also nice. These
features may not be necessary but it is a nice plus that with UMSDOS the
user has the option to use these tools the repair any problems (or
optimize).
>--
>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/