OSDev.org

I've had experience on the contrary. I have had instances when my Linux kernel refuses to let me open the drive. I have to reboot the system to get the disc out. This is a disc I only mounted in a command line, ran dpkg over, then tried to unmount.

Neither way is perfect. No way ever is. What I dream of at night is our internet connections getting so fast we don't have any removable drives. Everything is done by file sharing over the internet.

I know also windows unmounts drives. But just when you remove them. In any other situation it's completely free from the mount command

What are you talking about? If you remove a flash drive in windows, you should right click it and say eject, otherwise the operating system might not have flushed its disk caches right. Same on linux, you just use the unmount command(you could also right click and select "Unmount volume.." in a desktop environment).

When it comes to unmounting linux and windows are exactly the same: you should really unmount them, but if you just pull the drive out, none of them will scream at you(although you could lose some data in both).

How many users ejects the drives on Windows? I've known I've to do that when I started using Ubuntu, that shows a message when I pull out a drive without unmounting.

Some people here says that you can mount a drive on /home to have your home directory on that hd. On Windows you have just to change the label and change the directories address (it's a bit long, but...)

If we're arguing over ease of use, then this is definitely not easy, especially something used so often as your home directory.

Yeah! It easier to change the HAL right? (I'm talking of a non power user POV)

AlfaOmega08 wrote:How many users ejects the drives on Windows? I've known I've to do that when I started using Ubuntu, that shows a message when I pull out a drive without unmounting.

No one is saying you should. But things just work a lot better when you do. By default Windows disables write-caching to save the user for having to unmount the drive. But this takes a large performance penalty, one which it's well worth it to learn to cleanly unmount and set the system default to write-caching on removable storage.

I guess the average user is not smart enough to unmount a drive M$ thinks?

To those of you commenting on how the HAL does all this great stuff for you: how many of you are planning on porting that program directly and completely into your OS? None of you? Then it really doesn't matter what it can do for you in some other OS, now does it?

And as far as write caching goes -- I still say that any OS should flush the cache periodically, indicate to the users that it's been done, and not complain when a storage device is removed if there is no cache problem. If a device is removed when there is a cache problem, the OS should immediately ask for the device back, and then unmount it cleanly, and say it's done so.

bewing wrote:If a device is removed when there is a cache problem, the OS should immediately ask for the device back, and then unmount it cleanly, and say it's done so.

Sounds like AmigaOS. No unmount function, just eject the floppy when you're done. If an app was in the middle of accessing that floppy, it just asked for it back. It asked for it by volume name and it only made the program that needed it block (Unlike classic MacOS's similar function that brought up a modeless dialog that blocked the whole system).

bewing wrote:And as far as write caching goes -- I still say that any OS should flush the cache periodically, indicate to the users that it's been done, and not complain when a storage device is removed if there is no cache problem. If a device is removed when there is a cache problem, the OS should immediately ask for the device back, and then unmount it cleanly, and say it's done so.

As far as the flushing the cache periodically. It's really hard to find the write amount of time since idle to do this, if you miscalculate it by even just a little bit you'll create crazy bottlenecks and defeat the purpose of write-caching. This is also impossible to do while you're currently have a file open, say a word processor document or else you'll run into large consistency issues.

AdHawk wrote:I guess the average user is not smart enough to unmount a drive M$ thinks?

No, the average user is just too lazy.

Anyway, there's always going to be that issue of which usb* or *: is your flash drive and which one is something else, unless of course drive names are based on volume names (but that system fails if you change your drive's name, or the volume name is the same between two drives).

Honestly the argument that the unix vfs sucks just because you have to unmount a drive is just stupid. I mean come on.

The point is that if you use caching for disk accesses(which any os of sufficient complexity should) then you should have to unmount you drives.

Brynet-Inc wrote:

JamesM wrote:Dude, that method of mounting a removable drive is ugly as hell...

I disagree, it's quite easy...

"Easy", and especially "Quite Easy" are not the same as either "stylish", "elegant", or even "desired".

Why not have both? Just use different volume names to name different file-system trees, with file-systems mounted on any volume root or directory you like.

I am quite new here and I planned to rather only read this forum for some months. But seeing this topic I get strange feelings, as if we had some religious question arising for quite a lot of you!?

Doesn't it simply boil down to the plain factors:
* What is the main target audience of your OS?
* Inside what environment / usecases will it be running?

(-> "What purpose has it, what do you intent?"

And match that with your own history / skill / ressources available.
* What is your designer/developer team like? (My guess: each of your OS projects is run by only rather small band of devoted developers?)

To introduce an example I take myself:

I am one guy doing "only after work projects". And I'd like to focuss myself on embedded ARM environment. For my system though "usability" will mean at first first "responsiveness" and "good real-time behavior": even if under massive stress my filesystem acceses must never block any of the other vital systems, hopefully speaking in terms of sub milisecond.

So when I remember on my ol' Windows inserting any cdrom or opening a new folder in that file-explorer - then dangling the whole system for some seconds... well, you see what I mean.

And my main target media would be flash- and /or USB-disks (and if my ressources ever will allow) some slow remote network filesystem via some IP/TCP-network layer or so...

And the filesystem should be also available on the "normal" PC-Computers, too - so I also will have to write drivers for the existing Linux/Windows.

You now can understand, that the thread here looks a bit odd for me!?

Do we really need to vote for/against drive letters vs root-tree design???

I think that question is just a very small (and for me rather unimportant) subset of design-issues that one has to work through to reach the goal of doing an own working filesystem!

Reading this thread I am thinking "If that is one of ones major problems, maybe one just should take the specification of an existing filesystem - one that suits your taste best - and first implement that. You'll learn alot on that road!"

Since I am at the very beginning of my project I'll take that for myself, too!

----
sorry if I posted too early and broke some of the guidelines/rules of this forum... I will try to seat back and read silently on for now

Hello and Welcome!

If you feel something about a topic, by all means post.

I agree with you that really the file system path separator chosen is a bit of an odd thing to vote on (which is why I haven't voted) and that it does ultimately come down to what you are trying to achieve in the way of target audience.

Ultimately, it's your OS, and you can use the ASCII character 'A' as a path separator if desired (although I admit this may cause a little confusion!).

Unfortunately, when it comes to Host OS, Programming Language and IDE, people do tend to get a little religious about it. I hope this wouldn't put off anyone coming to these forums for the first time.

Having said all that, I do think it is an important design decision - selecting the incorrect way of handling your file system could potentially put off both users and third party developpers (It would have been daft for ReactOS to choose the /dev/hdx method of accessing a device, it would also be daft for someone aiming for a unix clone to use c:\my documents...).

Cheers,
Adam

Well, I think most systems store them internally as a list or tree, it's just a matter of how you want to present them to the user. I plan on having mine viewable from the directory, and then something similar to my computer where it lists all the partitions/devices. The difference is, instead of having them listed by a character (A,B,C) I will just have the drive's name (similar to how windows displays this next to the drive letter). So when referencing a device, it will be by name. How simple/hard the user chooses to make these names is them up to them, they can name them C, D, E, F if they'd like (and since it's encoded on the drive/fs it will stay consistant when removed/inserted), or they can name then hd0, hd1, fd0, or... WorkDisk, USBDisk, FlashDrive, etc. The links on the file system under root/dev/block will also use this name, so it will make sense while browsing manually as well.

To the guy above (TverrBjelke), stuff like this may not seem important right now, but it will eventually be. True, this may not be one of those "omg, if I can't get this right my OS will never work properly", because lets face it, this is typically how you display the device to the user and does not affect to much of how the device is handled internally, so I do agree that this shouldn't be a 'major' design decision, but it does have to be a decision at some point (before you start laying out to much of your system, because how do your drivers/etc search for devices, do they do it by hd0, hd1, etc, do they check for names, do they use the internal format, do they search through a VFS directory, etc). It may not seem like much of a question, but it can make a big difference in your underlying system, for example, try storing devices one way, then deciding you want to use it as a VFS (Virtual file system), and have to fix everything that access a device to find it another way instead of the proprietary interface. Depending on how far along you are, and how you store the devices internally, it may be simple, and it may be a huge pain.

I will go even farther than Ready4Dis -- there are only one or two major design decisions to make regarding your OS. You make those before you even start. After that, it is a matter of nailing down about a thousand (or perhaps more than that -- I haven't counted them all, as I made the decisions) minor design decisions just like this one. When faced with one of them, you need to be able to form a strong opinion about every single one of them. There is nothing more frustrating than spending two weeks dithering over a design decision that you already know is only a minor design issue anyway.

bewing: funny, I don't consider any design decision to be a minor one, but that might be me One thing I have learned is what looks to be a small insignificant design decision in the end might turn out to be a major one. Especially things that have to do with security and user interaction with the system.

Read4Dis: I'm wondering what you're going to do when a user attaches two drives / discs with the same volume name... any thoughts on that?