On Thu, Jul 25, 2019 at 08:21:02PM -0400, Greg Troxel wrote:
tlaronde%polynum.com@localhost 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.
I was not thinking that this was NetBSD that had to be fixed ;-) I
always thought that when umount(8) was done then everything was fine.
But with the disk still making write noises after that I wondered if my
assumption was right or if the cache policy could be in the
middle---then went this experience of writing a lot of data on a USB
disk under Windows, with command line, the command line returning but
the disk still writing during a long time (it is not exactly the same
since Windows with its volumes, automounting etc.).
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.
I need to verify if the informations about the cache are consistant
between a USB connection and a eSATA one. It seems they are not the
same. Cache info can be accessed with dkctl(8) (general), atactl(8) or scsictl(8)
depending on the connection (and USB emulates SCSI if I'm not mistaken).
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.
I need to investigate more. I know that I will already tell to not use
the kind of docking station I'm testing (without even a led to show disk
activity, it's simply useless). But I can gather more knowledge about
what is going on or can be going on when someone plug a "bad boy", so I
will keep it until I have a more clear understanding and what is going
on and who is doing what.
Best,