> 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
-
To unsubscribe from this list: s
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
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 foll
> 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 bd
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 sa
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
6 matches
Mail list logo
