DOS VS Unix drive accessing
- AlfaOmega08
- Member
- Posts: 226
- Joined: Wed Nov 07, 2007 12:15 pm
- Location: Italy
DOS VS Unix drive accessing
In DOS and Windows, we use "a:" "b:" "c:" ... to access to the various drives and partitions.
On Unix we use a (according to me) complex system which is made of mounting all the drives to a root file system...
Personally I prefer the first one. But what are the difference. Wich is the faster, and there is something I can do with one and can't with the other?
On Unix we use a (according to me) complex system which is made of mounting all the drives to a root file system...
Personally I prefer the first one. But what are the difference. Wich is the faster, and there is something I can do with one and can't with the other?
Last edited by AlfaOmega08 on Mon Apr 14, 2008 5:16 am, edited 1 time in total.
I prefer a variation of the first method, too. There is no difference. It is only a matter of taste. Unix people will say: "but look! It's just one single tree!" Meh. Theoretically, that would make it easier for a recursive function to traverse every mounted filesystem, all at once. On the other hand, it makes it much harder NOT to traverse particular filesystems -- because an app has a hard job finding out which physical partition any particular directory belongs to, and there is no convenient way to present that info to the user.
I think today's users understand very well which data is on which partition of which drive. So it is best to separate out the filesystems according to the user's understanding of the filesystem's physical organization. Which means separating out each partition into its own tree.
I think today's users understand very well which data is on which partition of which drive. So it is best to separate out the filesystems according to the user's understanding of the filesystem's physical organization. Which means separating out each partition into its own tree.
- karloathian
- Posts: 22
- Joined: Fri Mar 28, 2008 12:09 am
From a user point of vue I think UNIX style file system has one advantage over the DOS style , in that you don't have to wonder on which drive you saved a file.
But on the other hand you the tree style system mounting is confusing for first time users, and ideally the best kind of VFS would be one that mixes both. By that I mean , a VFS that mounts folders as a folder and not determined by whats inside ( for example devices get mounted at /dev ) , but keeping it all in a single drive , to avoid the whole "file saving" issue.
But thats only my personal opinion.
But on the other hand you the tree style system mounting is confusing for first time users, and ideally the best kind of VFS would be one that mixes both. By that I mean , a VFS that mounts folders as a folder and not determined by whats inside ( for example devices get mounted at /dev ) , but keeping it all in a single drive , to avoid the whole "file saving" issue.
But thats only my personal opinion.
Hi,
I prefer the UNIX way of a filesystem. It is connected with the philosophy of UNIX: "make all as simple as possible". I am writing a microkernel and I think the thought behind microkernels is the same. I also implemented a UNIX-like VFS.
I think UNIX-like VFS' have several advantages, but they are hard to describe.
I prefer the UNIX way of a filesystem. It is connected with the philosophy of UNIX: "make all as simple as possible". I am writing a microkernel and I think the thought behind microkernels is the same. I also implemented a UNIX-like VFS.
I think UNIX-like VFS' have several advantages, but they are hard to describe.
The big advantage unix-like FS layouts have over windows ones is that of location transparency. System administrators can (seemingly) transparently change the implementation of, say, one's /home directory. An example being that at work all our home directories were moved from one implementation (NFS share) to another (SAN). On windows this would be quite a faff, as links would need to change, but on unix it all happened transparently.
The big advantage that windows-like FS layouts have over unix-like layouts is opacity. It's easy to tell where file x:\foo\bar is stored - it's on drive x. It's given in the filename! It's a little more intuitive than the unix system, but one might argue that's more nurture than nature - most people are brought up on windows boxen and changing to unix is just that - a change. I think a similar "oooh, it's different, I don't like that" argument can probably be put forward for unix gurus moving to windows.
Cheers,
James
The big advantage that windows-like FS layouts have over unix-like layouts is opacity. It's easy to tell where file x:\foo\bar is stored - it's on drive x. It's given in the filename! It's a little more intuitive than the unix system, but one might argue that's more nurture than nature - most people are brought up on windows boxen and changing to unix is just that - a change. I think a similar "oooh, it's different, I don't like that" argument can probably be put forward for unix gurus moving to windows.
Cheers,
James
The first thing you gotta realize is UNIX has no concept of drives at the VFS level. You could have a filesystem that is only backed up by memory or even one that goes over the network. The VFS does exactly what it says -- it is a virtual file system.
Now on to my own humble opinion.
UNIX is simply more flexible than windows. I think windows drive naming forces the user to use a really stupid and old system. For example, right now I have three hard drives on my linux box and I use each of them for a different directories(like /home, /usr and the root itself). With windows, I would basically be stuck using different drive letters to refer to all my files.
Secondly, drive letters are cryptic. In UNIX I could configure the path to my cdrom to be /media/cdrom. Unlike d:, this path tells me two things, first of all it is a removable media and it is a cdrom. D: tells me nothing.
I know windows can do what linux does with some fancy subst commands, but in linux the idea is simply so much more pervasive and easier to achieve. Also, in linux, it is entirely possible to have different directories refer to different drives. For example, HAL can automount your disks under /media/<name> where name is whatever HAL thinks is the name of the disk.
@JamesM I completely agree that it is more nurture vs nature. I used to use windows exclusively. Then I switched to linux and I absolutely love using the VFS. At first I must admit it was a real burden. But then I gradually figured out how it is so much better. The ability to mount the same filesystem in to places is a really useful tool in addition to the symlinks, etc.
@bewing why would you care which physical partition it's on? I mean, when you put removable media inside, it gets mounted to wherever the user configured it. For me that is /media/cdrom. Personally /media/cdrom is so much more telling than d: or even e:.
Now on to my own humble opinion.
UNIX is simply more flexible than windows. I think windows drive naming forces the user to use a really stupid and old system. For example, right now I have three hard drives on my linux box and I use each of them for a different directories(like /home, /usr and the root itself). With windows, I would basically be stuck using different drive letters to refer to all my files.
Secondly, drive letters are cryptic. In UNIX I could configure the path to my cdrom to be /media/cdrom. Unlike d:, this path tells me two things, first of all it is a removable media and it is a cdrom. D: tells me nothing.
I know windows can do what linux does with some fancy subst commands, but in linux the idea is simply so much more pervasive and easier to achieve. Also, in linux, it is entirely possible to have different directories refer to different drives. For example, HAL can automount your disks under /media/<name> where name is whatever HAL thinks is the name of the disk.
@JamesM I completely agree that it is more nurture vs nature. I used to use windows exclusively. Then I switched to linux and I absolutely love using the VFS. At first I must admit it was a real burden. But then I gradually figured out how it is so much better. The ability to mount the same filesystem in to places is a really useful tool in addition to the symlinks, etc.
@bewing why would you care which physical partition it's on? I mean, when you put removable media inside, it gets mounted to wherever the user configured it. For me that is /media/cdrom. Personally /media/cdrom is so much more telling than d: or even e:.
I'm sort of on the fence on this... did or did I not save that on the external drive that I'm about to hand to some other person? Does this drive have enough free space to save what I need?karloathian wrote:From a user point of vue I think UNIX style file system has one advantage over the DOS style , in that you don't have to wonder on which drive you saved a file.
That's extremely easy to do under Windows too... it's called roaming profiles and you can also change where these folders point to. Problem is that lazy programmers always assume paths to be in a certain location while that might not be true (different locale, pointed to network drive or different volume, etc.). This is why there's an API under Windows that tells you where the path of "my documents" is.JamesM wrote:System administrators can (seemingly) transparently change the implementation of, say, one's /home directory. An example being that at work all our home directories were moved from one implementation (NFS share) to another (SAN). On windows this would be quite a faff, as links would need to change, but on unix it all happened transparently.
Yes, but that might still be on a network, or redirected to a different drive / volume (subst).JamesM wrote:It's easy to tell where file x:\foo\bar is stored - it's on drive x.
Don't really see how /home would be different than D:, but you can do the exact same thing under Windows these days through mountvol command-line tool. The technique is called volume mount point and allows you to mount a drive anywhere in another folder structure.iammisc wrote:UNIX is simply more flexible than windows. I think windows drive naming forces the user to use a really stupid and old system. For example, right now I have three hard drives on my linux box and I use each of them for a different directories(like /home, /usr and the root itself). With windows, I would basically be stuck using different drive letters to refer to all my files.
Windows actually offers you to do this when you create a partition. It will ask you if you want to mount it as a drive or as a folder on another volume. It can also do both at the same time if you want.
Same under Win, except for automount (but it will remember how you mounted it last time).iammisc wrote:Also, in linux, it is entirely possible to have different directories refer to different drives. For example, HAL can automount your disks under /media/<name> where name is whatever HAL thinks is the name of the disk.
I personally utilize drive letters, mount points and VFS in my daily live dealing with XP, 2008 server, Vista and OS X. It's definitely interesting from an OS developers perspective how different OS'es have implemented things and how that has changed over the years.
Since this is my first post as a registered user I'll point to one of my previous threads here that I posted without an account: http://www.osdev.org/phpBB2/viewtopic.php?t=11444 (and yes, that site will be up soon again)
It's good to see people like Brendan, Candy, Dex, Solar and numerous others are still around!
Last edited by robos on Mon Apr 07, 2008 12:50 am, edited 1 time in total.
- Rob
I prefer windows, like mentioned, you can easily mount a partition/drive to a folder under and recent windows OS, so that argument just doesn't stand anymore. It allows me to easily view a drive/partition to see how much space is used and free. I don't know who was arguing about changing devices for user profiles, but you can easily set user home directories in windows, and make any changes necessary without problem. You can mount a network drive and point to a user folder with their username, if you want to change file systems, or put a different hard disk, etc, you simlpy re-mount a different drive, which is the same as what you are doing under unix. I don't know if using the alphabet to name my partitions/drives is the best method, and I do think a tree of sorts is useful (which i'm sure windows uses internally), but i also like being able to chose a drive by itself, and windows provides both abstractions (and gives me the choice to use one or both). I do like the concept of unix vfs and it's integrated in the OS, but I think an interface to see physical drives/partitions would be nice to have on-top of it (which would pretty much bypass VFS). I do admit I have used windows more than *nix, so my opinion may be biased, but I plan on following a similar method to windows, where you can mount drives -> partitions, but also have the actual device available directly.
The main problem with drive letters in Windows is, imho, that you never know which drive letter you'll get for removable drives. In the old days it was simple, you had A: and B: for removable diskettes. But then you got CD-ROM drives, ZIP drives etc., but at least the drives were permanent if not the media. But now, with USB sticks and media cards it's a real pain to know which drive is which. If I plug in a USB stick, it can be anywhere from D: to G:, depending on the USB port used and the other devices active.
That said, a good OS of course completely abstracts all this muck from the user. It has, e.g. a "places" or "locations" bar / menu / whatever so you can choose from the attached removable media. In that respect, the low-level representation of physical drives, logical partitions, removable media and the like is a non-issue.
JAL
That said, a good OS of course completely abstracts all this muck from the user. It has, e.g. a "places" or "locations" bar / menu / whatever so you can choose from the attached removable media. In that respect, the low-level representation of physical drives, logical partitions, removable media and the like is a non-issue.
JAL
UNIX doesn't solve this... /media/usb0 is a USB drive to be sure... but which one? The best solution to that problem, IMHO, is to put the drive label in the filename: /media/jack-usb or jack-usb:/ etcjal wrote:The main problem with drive letters in Windows is, imho, that you never know which drive letter you'll get for removable drives. In the old days it was simple, you had A: and B: for removable diskettes. But then you got CD-ROM drives, ZIP drives etc., but at least the drives were permanent if not the media. But now, with USB sticks and media cards it's a real pain to know which drive is which. If I plug in a USB stick, it can be anywhere from D: to G:, depending on the USB port used and the other devices active.
The problem is, you don't know which device is plugged in and where, now you can give the file system/partition a name, and use that to map the device, which will work in some cases. You could use the device name to give it a unique identifier, which works in some cases as well. You could use the device's serial number (if it returns one, not all do this) to keep track of where it should go/what it is. So, now we have a problem.. a bunch of devices, not a single "generic" way to store which device should be what. I mean, calling them hd0, hd1 is great, but then if you plug/unplug USB devices, you are back to the same issue as windows assigning random letters. If you determine it based on it's file system name, what's to stop 2 devies (since most come pre-named from the factor) from having the same name? You can use the serial # for IDE devices, but that info isn't available to USB drivers all the time (or do all mass storage devices have unique ID's?). You could store a file on the filesystem of the disk that is set the first time it's installed, which will always work as long as it's not modified/formatted (ala, windows volume information files), which is why when your device is assigned letter g:, and you plug it in again to another port, and you only have devices to c: at the time, it will still register as the g:, because it remembers the device using the volume information. Now, if something else has taken the letter g:, it cannot re-use the assignment (this is a problem that should be dealt with), but in general works pretty well. I am not 100% sure how unix does this, as i mostly use windows (as stated above), but I assume it stores some of the mount information on the device it self (except in cd-rom cases where it can't, which begs the question, how does it handle multiple USB cd-rom devices?). No method currently available today is perfect, when i need to know which device is which, i open my computer and look, it has the name and size right there for my viewing pleasure, and i know what devices i have in my computer, and what drive letters are currently assigned, so when a new one pops in the list, i know that's the device i just put in... like I said, not perfect, but nothing really is.
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
On Unix, drives aren't automatically mounted.. Or at least, they shouldn't be.. Linux+FreeBSD+HAL tend to be doing that these days.
On this workstation, I have one MBR partition covering the entire drive, and 6 BSD disklabel partitions for /, /tmp, /usr, /var and /home.
Obviously, I can trace back each mount point by issuing the "mount" command, with no options..
If for some reason I need to mount a removable device, I can either make an educated guess, or parse the dmesg+/var/log messages using grep to find its name, afterwards fdisk and disklabel to determine the partition..
"dmesg | grep sd" would show all detected "SCSI" devices, (USB mass storage for instance, or SATA), determining which drive was which would be easy, using 1 or more identifying factors, such as device size, product manufacture, or partitions.
I think the DOS/Windows style is primitive, highly so..
On this workstation, I have one MBR partition covering the entire drive, and 6 BSD disklabel partitions for /, /tmp, /usr, /var and /home.
Obviously, I can trace back each mount point by issuing the "mount" command, with no options..
If for some reason I need to mount a removable device, I can either make an educated guess, or parse the dmesg+/var/log messages using grep to find its name, afterwards fdisk and disklabel to determine the partition..
"dmesg | grep sd" would show all detected "SCSI" devices, (USB mass storage for instance, or SATA), determining which drive was which would be easy, using 1 or more identifying factors, such as device size, product manufacture, or partitions.
I think the DOS/Windows style is primitive, highly so..
Dude, that method of mounting a removable drive is ugly as hell...Brynet-Inc wrote:On Unix, drives aren't automatically mounted.. Or at least, they shouldn't be.. Linux+FreeBSD+HAL tend to be doing that these days.
On this workstation, I have one MBR partition covering the entire drive, and 6 BSD disklabel partitions for /, /tmp, /usr, /var and /home.
Obviously, I can trace back each mount point by issuing the "mount" command, with no options..
If for some reason I need to mount a removable device, I can either make an educated guess, or parse the dmesg+/var/log messages using grep to find its name, afterwards fdisk and disklabel to determine the partition..
"dmesg | grep sd" would show all detected "SCSI" devices, (USB mass storage for instance, or SATA), determining which drive was which would be easy, using 1 or more identifying factors, such as device size, product manufacture, or partitions.
I think the DOS/Windows style is primitive, highly so..
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact: