I have a question about the struct ide_drive_s member removable.
The problem with it is that I have an IDE flash disk that sits on normal IDE bus and this removable flag gets set because the IDE ID info has the bit set for removable. Because this flag is set, idedisk_media_change will return true every time media change check is done. This happens every time when partitions are being mounted.
Now, because idedisk_media_change tells the media is changed, the system invalidates all buffers. This is bad when the dirty buffers on some of the partitions have not been written to the disk. Data is lost and file system is corrupt.
I suppose the device tells it is removable because the controller on the disk is also used with some PCMCIA IDE devices.
I am curious if this idedisk_media_change return value is needed with some removable disks. I do not know any. I think that in case of a PCMCIA, the whole IDE controller is removed and that should invalidate all buffers.
Currently I have just patched the kernel to clear the flag for this particular disk.
But I'd need your help in finding a real fix to the problem.
[email protected] wrote:
> I have a question about the struct ide_drive_s member removable.
>
> The problem with it is that I have an IDE flash disk that sits on normal IDE bus and this removable flag gets set because the IDE ID info has the bit set for removable. Because this flag is set, idedisk_media_change will return true every time media change check is done. This happens every time when partitions are being mounted.
>
> Now, because idedisk_media_change tells the media is changed, the system invalidates all buffers. This is bad when the dirty buffers on some of the partitions have not been written to the disk. Data is lost and file system is corrupt.
>
> I suppose the device tells it is removable because the controller on the disk is also used with some PCMCIA IDE devices.
>
> I am curious if this idedisk_media_change return value is needed with some removable disks. I do not know any. I think that in case of a PCMCIA, the whole IDE controller is removed and that should invalidate all buffers.
>
> Currently I have just patched the kernel to clear the flag for this particular disk.
>
> But I'd need your help in finding a real fix to the problem.
Your analysis of the problem is entierly right, since the current
kernel behaviour for removable media is supposed to work for
floppies (never get this thing out of your computer
as long as long the diode blinks) or read only media where it doesn't
really matter. However I still don't see a good way to
resolve this issue. (Maybe just adding buffer cache flush before
going into the check_media_change business of "grocking" partitions
would be sufficient...
> Your analysis of the problem is entierly right, since the current
> kernel behaviour for removable media is supposed to work for
> floppies (never get this thing out of your computer
> as long as long the diode blinks) or read only media where it doesn't
> really matter. However I still don't see a good way to
> resolve this issue. (Maybe just adding buffer cache flush before
> going into the check_media_change business of "grocking" partitions
> would be sufficient...
But there is ide-floppy and ide-cd with their own media_check functions.
I'm thinking about ignoring the removable bit, at least when the device
does not have door lock. What would be hurt by it?
P.S. Sorry for the previous mail with long lines. I should know better
than using Outlook...
Marko Kohtala wrote:
> > Your analysis of the problem is entierly right, since the current
> > kernel behaviour for removable media is supposed to work for
> > floppies (never get this thing out of your computer
> > as long as long the diode blinks) or read only media where it doesn't
> > really matter. However I still don't see a good way to
> > resolve this issue. (Maybe just adding buffer cache flush before
> > going into the check_media_change business of "grocking" partitions
> > would be sufficient...
>
> But there is ide-floppy and ide-cd with their own media_check functions.
>
> I'm thinking about ignoring the removable bit, at least when the device
> does not have door lock. What would be hurt by it?
I have currently already just compared the ways invalidate_device() is
used in different linux block device drivers. And guess what... The way
it get's currently used in ide code are bogous. This will changed soon
and should help your problems. (Soon means - if the weather doesn't
remain good over this weekend ;-). However please feel free to have a
look after this yourself.