Hello,
It appears that the umount path in the 2.2 series kernels
does not do anything to invalidate the buffers associated with the
unmounted device. We then rely on disk change detection on a
subsequent mount to prevent us from seeing the old super_block.
Since deja was gobbled by google it's hard to do a good search of
this list. Can anyone take the time to help me understand the reason
for this choice? This seems to me to be backwards. When a device is
unmounted there should be no cached information.
Thanks for the help,
Phil
--
------------------------------------------------------
Philip R. Auld, Ph.D. technical staff
Egenera Corp. [email protected]
165 Forest St, Marlboro, MA 01752 (508)786-9444
> does not do anything to invalidate the buffers associated with the
> unmounted device. We then rely on disk change detection on a
> subsequent mount to prevent us from seeing the old super_block.
2.2 yes, 2.4 no
Alan Cox wrote:
>
> > does not do anything to invalidate the buffers associated with the
> > unmounted device. We then rely on disk change detection on a
> > subsequent mount to prevent us from seeing the old super_block.
>
> 2.2 yes, 2.4 no
That can be a problem for fiber channel devices. I saw some issues with
invalidate_buffers and page caching discussed in 2.4 space. Any reasons
come to mind why I shouldn't call invalidate on the the way down instead
(or in addition)?
Thanks,
Phil
------------------------------------------------------
Philip R. Auld Kernel Engineer
Egenera Corp. [email protected]
165 Forest St, Marlboro, MA 01752 (508)786-9444
> That can be a problem for fiber channel devices. I saw some issues with
> invalidate_buffers and page caching discussed in 2.4 space. Any reasons
> come to mind why I shouldn't call invalidate on the the way down instead
> (or in addition)?
The I/O completed a few seconds later anyway when bdflush got around to
writing the data back out. I dont plan to change 2.2. 2.4 doesnt do that
optimisation which is annoying in a few cases and a lot less suprising in
others
Philip R. Auld writes:
> Since deja was gobbled by google it's hard to do a good search of
> this list. Can anyone take the time to help me understand the reason
> for this choice? This seems to me to be backwards. When a device is
> unmounted there should be no cached information.
Try the following for a searchable mailing list:
http://marc.theaimsgroup.com/?l=linux-kernel&r=1&w=4
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Alan Cox wrote:
>
> > That can be a problem for fiber channel devices. I saw some issues with
> > invalidate_buffers and page caching discussed in 2.4 space. Any reasons
> > come to mind why I shouldn't call invalidate on the the way down instead
> > (or in addition)?
>
> The I/O completed a few seconds later anyway when bdflush got around to
> writing the data back out. I dont plan to change 2.2. 2.4 doesnt do that
> optimisation which is annoying in a few cases and a lot less suprising in
> others
Sure, the I/O completes, but the buffer_head is still in memory, valid and
uptodate.
On a subsequent mount the super_block comes from memory not disk. This works
as long as nobody else mounted that file system in between.
I can make the changes needed. I was really curious if you, or anyone else,
thought there might be page caching issues involved with invalidating on the way
down.
Thanks the time,
Phil
------------------------------------------------------
Philip R. Auld,Ph.D. Techinical Staff
Egenera Corp. [email protected]
165 Forest St, Marlboro, MA 01752 (508)786-9444
> I can make the changes needed. I was really curious if you, or anyone else,
> thought there might be page caching issues involved with invalidating on the way
> down.
2.4 already addresses this. With 2.2 or 2.4 you can force buffer flushes from
userspace too