Mike Burger wrote, On 03/03/2008 04:14 PM:
Instead of having this in your fstab, you might want to try using the
automount daemon handle this drive. That way, it's only mounted when you
actually need it, and unmounts after a period of inactivity.
Works for me...I use external drives for my Mondo backups, so that I can
take the drives offsite.
Hi. I'm still tweaking my setup with my external USB hard drive.
It's generally working, but it still has this annoying habit of
getting lost, with messages like these:
Mar 3 10:33:33 pigpen kernel: usb 3-1: USB disconnect, address 4
It "only" happens every few days on average now. When it does happen,
though, I manually umount, e2fsck, and mount it. I did create an
fstab entry so can refer to it as "/mnt/disk2", but it's still a bit
tedious, and the filesystem is unavailable until I notice that it's
missing. So I'm wondering if there's a good way to automate this. I
know about autofs, which should work, but that implies a lot of
mounting and unmounting (depending on timeouts and access frequency),
when logically this is a permanently attached drive. The ideal thing
is if there was a way to perform my umount/e2fsck/remount whenever it
gets lost. Shortly after getting lost, the kernel finds it again, so
it seems analogous to unplugging and replugging the USB cable. Is
there a proper fedora way of handling this? I run KDE, not GNOME, but
it seems like any solution should be independent of desktop
environment; i.e. at a lower level and not dependent on a user being
logged in. If autofs is the best way to go, that's fine.
(For the record, it was disconnecting much more frequently when I had
my wireless router right next to it. I moved the router a few feet
which seems to have helped some. It may be completely unrelated, who
knows....)
Set the wireless router right on top of the drive for a while, then set it
under the drive for a while. :)
if the frequency goes back up, I would say you have a high likely hood of
having found the problem, if so please remind us what HD manufacturer is
affected by the RF so we can avoid one or the other. :)
Granted I would also move the router away again and try setting the drive in
different orientations to see if a connector was affected (i.e. loose).
To me having autofs setup with a timeout much smaller than you are seeing the
fault would be a good thing for a few reasons:
1) drive is not mounted during a fault, no fsck needed.
2) drive is not mounted when not needed, see (1)
3) mounting should cause the drive to spin up and all that jazz so that, it is
ready to work WHEN someone needs it.
You might want to tune2fs and raise the fsck timeouts because they will go up
a little quicker this way.
You'll need to fsck by hand when ever you feel the need, or get tired of
seeing "mounting drive that needs fscked" in syslog and dmesg, it will not
happen automatically.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
