Re: safely remove USB hard drive

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

 



On Thu, 2008-04-24 at 11:33 -0500, Mikkel L. Ellertson wrote:
> 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.

It's possible that 'eject' can handle such a drive-specific command, but
again the man page doesn't say so. Disabling write-caching may not
always be possible, it depends on the drive itself. Some drives may even
do caching without telling you (many of them already mess around with
the internal geometry so what they present to the outside world is not
always the truth). Designers trying to be clever make it harder for
driver software to be clever.

> > 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...

I assume you mean vulnerable (NFS is also venerable :-). That's what
soft mounts are for BTW, but at the risk of data loss. You can't have
everything.

> 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.

The old Unix man pages were models of clarity and concision (I'm
talking about 6th Edition, often regarded as an improvement not only on
its predecessors but also its successors :-). Unfortunately that's been
lost. If the man pages are not reliable, and there's no official spec as
to what all this stuff is theoretically supposed to do (i.e. what are
the guarantees?) then we're reduced to black-box testing and/or reading
the source, and even that can change from one minor release to another.
The only reason it usually doesn't is that Linus and pals are fairly
responsible people.

poc

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux