Re: safely remove USB hard drive

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

 



On Thu, 2008-04-24 at 10:49 -0400, Joe Smith wrote:
> Thanks for the input, folks.
> 
> Using the GUI is not terribly convenient, because I have to open the
> "Computer" folder, identify and select the correct partitions from among
> the other items there (filesystem & other devices; maybe a whole bunch
> of stuff if Nautilus is showing all your mounted partitions). But it
> does work.
> 
> It's probably better to use the GUI from the desktop, from the
> standpoint that applications that need to know about a device being
> removed can be notified.
> 
> I was more interested whether someone had a way to "eject" the device
> (i.e. a single 'thing') without having to deal with all the partitions
> separately. In fact, it seems like it would be a win all around if the
> 'drive' appeared as a directory, and then the partitions on the drive
> were mounted under that. Ejecting or unmounting the drive object would
> then unmount all the partitions.
> 
> In fact, "eject /dev/sdd" works perfectly--even the desktop is updated
> correctly--the only problem is that I have to poke around in the logs to
> see what 'sd' device name the drive is using. Exposing that on the
> desktop somewhere would be perfect.
> 
> Anyone know how Windows or Mac handle this? My USB HD has only one FAT
> partition, so I can't test it easily.
> 
> Maybe this is all moot, as most people won't partition external
> hard drives ;-) I happen to be using mine for access to retired system
> drives, and some of them have 6 or more partitions.
> 
> I'm not convinced that using sync(1) would be effective, especially from
> the desktop environment where who knows what processes have something
> open on a pluggable device. Sync would be prudent if you were moving raw
> data blocks to a device, but not for mounted filesystems.

Of course sync is effective for mounted filesystems, why wouldn't it be?
It means data are now synched *up to this point*.

> Eject(1) calls unmount on the device; unmount guarantees that all
> OS-cached data are flushed before the device is unmounted. I can't
> /prove/ that easily, but I can't see how it would be a sane design
> otherwise. There's no real advantage in using 'eject' instead of
> 'umount'; eject is nice for some removable media and it's simpler to
> just use the same command for all removable media, even if some of them
> can't physically eject anything.

>From the man page for eject(1):

        "If eject determines that the device can have multiple
        partitions, it will attempt to unmount all mounted partitions of
        the  device before ejecting. If an unmount fails, the program
        will not attempt to eject the media."
        
So it looks like that's what you want.

There is no documentary evidence that unmount calls sync (contrary to
what many people think, including me up to about yesterday). The
eject(1) page doesn't mention syncing or flushing buffers.

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