Quote:

What is it with cats and power cords anyway???

Anyway, yeah, JFL65's idea is better than a supermount approach -- just keep those write buffers flushed, which also means it would be better to have the mounting process ignore unmounted states (filesystems have a "mount bit" -- a bit that is turned on when they are mounted and off when they are unmounted. It's used to tell if a filesystem was left mounted when the power went off. I think it's best that AROS just ignore this bit).

Might also be a good idea to stick to atomic filesystems, filesystems which commit every write to the device with the filesystem in a coherent state when its complete. That way, even if the power does go off during a write, you won't get a corrupted, useless filessystem (though you may lose the last part of whatever file you were writing to at the time).

So life becomes very simple. Be kind to one another, brush your teeth after every meal, and keep those write buffers flushed.

[quote]or the cat might chew through a cord/quote]Kentucky Fried Kitten

I have a better idea - these other filesystems have to be ported to AROS anyway, so while porting them, just make sure you add some code to flush the write buffers after a few seconds. The only reason you would NEED to do a shutdown is data written to a filesystem is still in a buffer in memory. That is stupid in my opinion. If it's not been written to disk within a few seconds, you're asking for trouble. People can't always shutdown properly - the power may go off on you and you don't have a UPS, or you may accidentally yank the plug out of the wall, or the cat might chew through a cord. Any number of things may happen. The longer the data sits in memory unwritten, the more trouble you are asking for. So make a rule that all ported filesystems MUST flush caches within a certain amount of time. No biggy. Pretty easy to do compared to actually porting the filesystem.

Actually I think this is something to be solved. It was always nice that you could just shut off the Amiga without worrying about it (as long as nothing was being written at the time). I think the solution is to deal smartly with filesystems that don't support this kind of shutdown very well.

AROS is a desktop OS. It should be shoving as few "you gotta do it this way because of some long string of technical..blah..blah..blah" garbage in our users faces as possible. People are used to being able to just turn things off when they are done with them and AROS should work the same way. Even technical users would PREFER this -- no one actually prefers having to go through extra annoying steps, they simply understand the reasons why they have to.

My idea, which isn't my idea at all and is in fact quite old and has been done in several systems already, most famously supermount:

Basically, when AROS encounters a foriegn file system, it should keep it "virtually unmounted" (that is, fully updated with all of it's write buffers written out as much as possible, and the mount bit off) all of the time. When some write requests come, AROS would flush them as soon as there is even a little break (like 1 second) in the stream, by mounting the filesystem, writing the changes, then unmounting the filesystem (virtually -- the file system would always _appear_ to be mounted), not like Linux which will rarely do routine flushes (eeeeew, icky -- didn't your mother tell you to FLUSH when you are done?). This would be done for EVERY drive, fixed or not. During the write cycle, the drive's icon would be updated with a little mark to tell you that you really ought not to turn off the machine right now. So we tell our users "Make sure that there's no littel red mark on any of the drives" -- that's even simpler than the "Wait two seconds and watch your drive lights" advice of the Amiga classic era. Reads would all be done without mounting the filesystem at all. For writes, this might make it a little slower, because the mounting process requires building a tree in memory of filesystem information -- but this could be cached even if the volume is in a (virtually) umounted state.

For native filesystems, it should just be a core part of their basic design, the idea that the power is going to go off at any time. So basically, a tolerant, atomic operation filesystem with as little write cache flush latency as possible would be the ideal one.

I really think this is better overall, even if it comes at the cost of some drive IO speed. AROS is a desktop OS -- it should be designed to work well in an unreliable world, not the pure, stark world of the server room. The cat will trip over the power cord, the storm will knock a tree into your towns main trunk, and your wife will pull out what she thinks is the lamp plug to make space for her laptop, even if you carefully "shutdown". When this happens, you are going to be much more concerned that the last save on your masterpiece you've been hacking on for the last 2 hours got flushed to the drive and that the filesystem is in a coherent state than you would be about that extra 0.78% performance boost you would have had, had it been designed in the Linux (server OS) way.

Erik

Quote:

Atleast one of the Devs thinks so too.

Dammy
TeamAROS

SFS would be nice

Because AROS will support multiple file systems and some of those file systems do NOT like power off without a tidy shutdown. Which means, there should be an option for a clean shutdown. End users, like yourself, can do whatever file system they wish and treat their drives accordingly.

I, OTOH, would like to see an optional clean shutdown as I am not really happy with AFFS and would prefer a more modern file system. AROS is about freedom of choice, right? =)

Dammy
TeamAROS

Why a need to shutdown? On a real Amiga you didn?t care about de shutdown.You just have to wait until the floppy writing/reading was sptopped, and then was no danger.

There is a standard bios command for doing this at least with ACPI bioses.. Not sure about just APM..