Re: External disk (umass) still writing: how to tell?

[tlaronde%polynum.com@localhost]

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,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C