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

[Greg Troxel <gdt%lexort.com@localhost>]

tlaronde%polynum.com@localhost writes:

You have said that you are hearing "write noises".  I would suggest that
you don't actually know that; you are simply hearing noises.  Writing
and reading are basically silent.  What you hear is rotation and
seeking.  It would not surprise me if the disk moved the heads to the
park position after 30s of inactivity, or something like that.

It should be easy to experiment by taking a spare disk of this type,
creating a fs, mounting it wapbl, and then running a script which untars
a large file and does unmount.  Unplug USB as soon as you get the
prompt.  On another run, unplug power as soon as you get the prompt.  In
each case, plug it back in, run fsck (should report clean, and with
force no problems), and check that the files are there.  Let us know if
you find anything interesting -- I hope you won't.

> I'm not an english native speaker so just to be sure: do you mean it is
> safe to unplug the board/device connection (this is not what is
> bothering me) or do you mean it is safe to cut the power on the disk
> (this is bothering me: if there is activity on the disk, since I can't
> know what exactly it is doing, it must not be put out of power).

If unmount has returned, then the OS has told the device to flush the
cache and gotten an acknowledgement.  So it is safe to turn off the
power, and it is safe to remove an interface cables, if it can be
removed safely when power is on.  USB is ok.

> My question was: does it mean that the OS can ensure that, when
> the umount has been done, all the data it has transfered has been
> written finally to the disk (physically) or could the disk still
> have the data in cache (for me: memory)---and this is how I interpret
> what you write: as far as the system is concerned, the data has been
> transferred; what the device does with it is another problem, meaning
> that a loss of power will be a loss of data erasing a cache not written
> to disk.

The disk will have responded to a cache flush command.  That means it is
now repsonsible for ensuring the bits are long-term safe even if it
loses power.

The point I have been trying to make is that there are specifications,
and then there are actual devices.   I have no idea what your actual
device does.

> Specially: if mounting with "sync" does the OS has the mean to
> ensure that the data is written physically to the disk (that could
> be powered off), waiting to return from umount until it is actually
> done---while without sync, it can return once the data is transferred
> as far as it (the OS) is concerned, but not waiting for the device
> to tell it has been "committed" actually to disk.

The sync option means that the OS waits to get an acknowledgement that
the metadata has been written before it writes data, when updating
files.  This is very slow and basically never used.  I do not believe
that this necessarily involves a cache flush or an indication that the
bits have reached stable storage.  So there is no reason to think that
the sync option will solve your problem - if indeed you have an actual
problem, rather than only a concern that there might be a problem.

In some disks, there is just a notion of completion where the bits could
be in the cache.   Some disks have the notion of "tagged command
queuing" that allows the OS to have mulitple outstanding requests.  I
have the impression that in this mode, honest completion indications are
given, and that there is some notion of write barriers.

See the following articles, and note "FUA" in the NCQ article.

https://en.wikipedia.org/wiki/Tagged_Command_Queuing
https://en.wikipedia.org/wiki/Native_Command_Queuing