Linux-kernel mailing list archive 1999-41,: Re: [patch] [possible race in ext2] Re: how to write get_block?

# Re: [patch] [possible race in ext2] Re: how to write get_block?

Andrea Arcangeli (andrea@suse.de)
Sat, 9 Oct 1999 23:53:01 +0200 (CEST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Krzysztof Halasa: "Re: Network iface is down but pingable"
- Previous message: Theodore Y. Ts'o: "Re: USB Device Allocation: Let's keep on track!"

On Fri, 8 Oct 1999, Mikulas Patocka wrote:

>Here goes quick'n'dirty patch. It does bforget(). It should prevent file
>corruption.

wrong patch. bforget give you no guarantee at all. bfoget always fallback
to brelse if necessary.

What I said about bforget in my old email is still true. The _only_ reason
for using bforget instead of brelse is to get buffer performances (that in
2.3.x are not so interesting as in 2.2.x as in 2.3.x flushpage is just
doing the interesting stuff with the real data).

The current design bug in 2.3.20pre2 and previous has nothing to do with
bforget.

The right fix is to do a query on the hash every time you overlap a buffer
on the page cache. If you'll find the buffer - you are going to overlap in
the page-cache - in the hash, then you'll have to flush it exactly as
flushpage does. My way has no cache coherency downside and it's completly
safe. It will impact a bit the CPU though. Still far better than 2.2.x
because the hash will be almost empty in 2.3.x compared with the huge one
of 2.2.x. I just had to do something like that to fix the ramdisk device.
Now I'll implement the thing.

Andrea

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Krzysztof Halasa: "Re: Network iface is down but pingable"
- Previous message: Theodore Y. Ts'o: "Re: USB Device Allocation: Let's keep on track!"