Re: safely remove USB hard drive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Patrick O'Callaghan wrote:
On Thu, 2008-04-24 at 10:28 -0500, Mikkel L. Ellertson wrote:
Patrick O'Callaghan wrote:
You've stopped using the filesystem, you sync to make sure everything's
hunky dory, then you unmount. If you can't be sure that activity has
stopped (i.e. there are no open files or current directories on the fs)
you have to hope that unmount will fail and let you know, but there is a
potential race condition if you're not careful. The only way to avoid
the race would be if 'unmount' included a 'sync' within the kernel, but
the docs don't say that. I imagine the reason it's that way is that
unmount can take an indeterminate amount of time, especially for
remotely mounted filesystems. Just speculating of course.

poc

By design, the default action of umount is to fail if there are any open files on the filesystem. I am not sure what potential race condition you are talking about - I would think that proper unmount code would first make sure the file system in not in use, then block opening of files on the file system, write any dirty buffers, and then unmount the file system.
The potential race is when the last process closes the last file, then
unmount goes into action. Unmount will find the fs 'unused' because
there are no open files, but the buffer system may not have finished
writing blocks to the device. Also, when the 'sync' command returns, all
you can be sure of is that the buffer flushing action has been started
in the kernel, *not* that the data is physically on the drive.

From the BUGS section of sync(2):
        According to the standard specification (e.g., POSIX.1-2001),
        sync() schedules the writes, but may return before the actual
        writing is done.  However, since version 1.3.20 Linux does
        actually wait. (This still does not guarantee data integrity:
        modern disks have large caches.)

If I am reading this correctly, it is talking about the buffers on the drive itself, if you have write buffering enabled on the drive. To get around this, you would have to send a command to the drive telling it to write its buffers to disk, and have some way to know that it has done this. A work around would be to make sure that write caching is disabled on any removable hard drive.
Also, as I've said before, it may be "reasonable" to assume that unmount
flushes the buffers, but the docs don't actually say this. We all
imagine sync(2) and umount(2) in the context of disks or pendrives, but
they are also supposed to work for other kinds of filesystem, including
NFS and so on.

For some file systems, you can use the sync option - but this does not help with NFS. Then again, any network file system is venerable it network problem...
As far as the man page goes, it may be in need or re-writing. You
are correct that it does not say it say it writes the buffers, but
it does not say it does not do this. So we are left guessing. It may
be that that the person that wrote the man page didn't feel it
needed to be covered. I have run into this before on other man pages.
Mikkel
--

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

Attachment: signature.asc
Description: OpenPGP digital signature

-- 
fedora-list mailing list
[email protected]
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux