lkml.org 
[lkml]   [1998]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Important: fs corruption with 2.0.33 and removable media

Richard Waltham (dormouse@farsrobt.demon.co.uk) wrote:
> Disk change is dependent on the drive reporting that the media has changed
> when it gets a SCSI command to do something. Its not something that the
> kernel keeps a track of.

Correct.

> Is your drive set to automatically spin down? I have tried one of these
> drives (a really old one) on this machine but cannot remember if it's always
> set to automatically spin down or whether it is set by one of the switches.

Yes, it automatically spins down. But that doesn't seems to matter.

> Could this be a bug in the drive firmware? eg remove media, load new, let it
> sit for sometime - maybe drive spins down and forgets disk change - mount
> new media, spins up and no disk change notification.

Might be. (Its my assumption, too)
Firmware Rev: 1314 (If anybody likes to know)

> This really sounds like a drive problem even if it is not set to spin down.
> It is the drives job to say the media has changed.

Well, that doesn't help me a lot... ;-)

What about invalidation of the buffer cache if a removable media is unmounted ?
Even if the failure for the disc change detection lies at the firmware.
I think its a *very* bad idea to cache fs buffers after umount, causing
a disaster. (Overwriting the superblock, free block list,... etc.)
This should never happen, even if there is no correct disc change detection.

Btw: The fs is ext2.

PS:
Sorry, my correct email address is: kleff@informatik.uni-bonn.de
[Never downgrade from TkRat 1.1 to 1.05 :-( ]



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.017 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site