Stale super_blocks in 2.2

Stale super_blocks in 2.2

[Phil Auld]

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.                        pauld@egenera.com
165 Forest St, Marlboro, MA 01752        (508)786-9444

Re: Stale super_blocks in 2.2

[Alan Cox]

> 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

Re: Stale super_blocks in 2.2

[Phil Auld]

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.                        pauld@egenera.com
165 Forest St, Marlboro, MA 01752        (508)786-9444

Re: Stale super_blocks in 2.2

[Alan Cox]

> 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

Re: Stale super_blocks in 2.2

[Phil Auld]

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.                        pauld@egenera.com
165 Forest St, Marlboro, MA 01752        (508)786-9444

Re: Stale super_blocks in 2.2

[Alan Cox]

> 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

Re: Stale super_blocks in 2.2

[Andreas Dilger]

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