Messages in this thread | | | Date | Tue, 19 Dec 2006 17:51:20 +1100 | From | Nick Piggin <> | Subject | Re: 2.6.19 file content corruption on ext3 |
| |
Linus Torvalds wrote: > > On Tue, 19 Dec 2006, Nick Piggin wrote: > >>We never want to drop dirty data! (ignoring the truncate case, which is >>handled privately by truncate anyway) > > > Bzzt. > > SURE we do. > > We absolutely do want to drop dirty data in the writeout path. > > How do you think dirty data ever _becomes_ clean data?
I wouldn't have thought it becomes clean by dropping it ;) Is this a trick question? My answer is that we clean a page by by taking some action such that the underlying data matches the data in RAM...
We don't "drop" any data until it has been cleaned (again, ignoring things like truncate for a minute). That's a bug! And try_to_free_buffers() is called from places outside the writeout path. This is our bug (or at least, one of our bugs that appears to have the same triggers and symptoms as people are reporting).
[...]
> In no other circumstance do we ever want to clear a dirty bit, as far as I > can tell.
Exactly. And that is exactly what try_to_free_buffers is doing now.
I still think you should have a look at the patch.
-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |