tlaro...@polynum.com writes: >> Another question is if your disk is following the specifications.... >> > > It's a not used disk but not new that I'm using as a guinea pig because > I don't trust it. It was in a Iomega enclosure with an ARM board, that I > bought several years ago (because I wanted to play with ARM and, at that > time, there were no Raspberry, Olimex and so on, at least sufficiently > known), it was cheap (and having seen one in---short---production even > too expensive for the cheap price) but totally unreliable. So even this > "not used" disk might be special (it already advertises bad sectors...).
I didn't mean if it was broken. I meant that there is a notion that (fuzzy) on cache flush commands, the cache is flushed and when the command returns once can be sure. It is possible for a device to just return that the write is done, incorrectly. This is after all how write caches work. So without knowing that your device is ok, it's hard to talk about changing netbsd, vs the problem being that you need a better-behaved device. > My problem is to be able to provide an user with a hint about when he > can unplug for sure the external disk (BTW, I saw a couple of days ago > an USB drive connected to a Windows node, when a command to remove files > was done---returned---and the device was still writing a couple of > minutes after---request for "ejecting" did say that the device was busy; > but nonetheless, a uninformed user could have unplug it right aways). People who don't know what they are doing can do arbitrary bad things! > It could make sense: in the USD (with SCSI other USB I think?), one can > not change the write cache policy (and it is obviously with a write > cache enable when it should not) while with SATA (SATA <-> eSATA) there > is a write cache and no read cache (mounting without "sync"). It's hard to believe there is no read cache. I think you should keep separate the notions of disabling caches and flsuhing them reliably. > All goes for the ergonomy: to be able to give a hint for the user about > when he can unplug. For USB, one could unplug the system still > running---if I can ensure that the data is written and the wedges > unmounted. The proper way is that when unmount returns, it's ok. If that's not true, there's a bug to be fixed, someplace. Departing from this core notion is madness.
