This sounds like it may have the same underlying cause as an issue I've
been experiencing.
Steps to reproduce:
1) Mount filesystem (Seagate 2TB USB disk)
2) wait a while, so the drive spins down
3) cd to a directory off the root of the mount point (the thing we're
looking for here is a directory that is already in the filesystem buffer
cache because of the filesystem mount). We want a directory that is not
empty.
4) ls
5) ls will hang for a while as the drive spins up (this is to be expected)
6) ls returns nothing
We now have a problem. The kernel thinks the directory is empty, even
when its not. The drive is spun up now, and the rest of the filesystem
will function normally, but that one directory will be considered empty
by the kernel until it has reason to interact with disk (which means
writing to the directory). Once the directory is written, its now corrupt.
My guess is that there is something in the USB subsystem that doesn't
deal well with the longer times necessary for bigger drives to spin back
up (this is not a problem on 1TB drives).
A workaround is to have little script that does a dd from the raw device
to /dev/null before attempting to access the drive - this will ensure
that its spun up. Needless to say, this doesn't work at all well for
some production operations (e.g. rsync backup to USB disk), where disk
I/O can cease for long enough for the drive to spin down in the middle
of the job.
--eli
On 8/26/11 9:51 PM, Kevin Oberman wrote:
I've run into an odd problem with dismounting file systems on a
Seagate Expansion portable
USB drive. Running 8-stable on an amd64 system and with two FAT32
(msdosfs) file systems
on the drive.
The drive is "green" and spins down when idle. If an attempt is made
to shutdown the
system while the drive is spun down, the system goes through the usual
shutdown including
flushing all buffer out to disk, but when the final disk access to
mark the file systems as
clean, the drive never spins up and the system hangs until it is
powered down. I've found no
way to avoid this other then to remember to access the disk and cause
it to spin up before
shutting down.
If I attempt to unmount the file systems when the drive is shut down.
the same thing
happens, but I can recover as the second file system is still mounted
and an ls(1) to that file
system will cause the disk to spin up and everything is fine.
This looks like a bug, but I don't see why the unmounting of an
msdosfs system does not
spin up the drive. It's clearly hanging on some operation that is not
spinning up the drive,
but does block.
Any ideas what is going on? Possible fix?
--
Eli Dart NOC: (510) 486-7600
ESnet Network Engineering Group (AS293) (800) 333-7638
Lawrence Berkeley National Laboratory
PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
