On Fri, Dec 29, 2006 at 07:52:15PM +0100, maximilian attems wrote:
> > The only -mm stuff I recall being in the Fedora 2.6.18 is
> > the inode-diet stuff which ended up in 2.6.19, though the xmas
> > break has left my head somewhat empty so I may be forgetting something.
> > What patch in par
On Fri, Dec 29, 2006 at 10:02:53AM -0500, Dave Jones wrote:
> On Fri, Dec 29, 2006 at 10:23:14AM +0100, maximilian attems wrote:
> > > On Thu, Dec 28, 2006 at 11:21:21AM -0800, Linus Torvalds wrote:
> > > > > That was a Fedora kernel. Has anyone seen the corruption in vanilla
> 2.6.18
> > >
Linus Torvalds a écrit :
going back to Linux-2.6.5 at least, according to one tester).
I apologize for the confusion, but it just occurred to me that I was
actually
experiencing a totally different problem: I set a root filesystem of
3Mib for
qemu, so the test program just didn't have eno
On Fri, Dec 29, 2006 at 10:23:14AM +0100, maximilian attems wrote:
> > On Thu, Dec 28, 2006 at 11:21:21AM -0800, Linus Torvalds wrote:
> > >
> > >
> > > On Thu, 28 Dec 2006, Petri Kaukasoina wrote:
> > > > > me up), and that seems to show the corruption going way way back
> > (ie going
> On Thu, Dec 28, 2006 at 11:21:21AM -0800, Linus Torvalds wrote:
> >
> >
> > On Thu, 28 Dec 2006, Petri Kaukasoina wrote:
> > > > me up), and that seems to show the corruption going way way back (ie
> going
> > > > back to Linux-2.6.5 at least, according to one tester).
> > >
> > > Tha
On Thu, 28 Dec 2006 17:38:38 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> in
> the hope that somebody else is working on this corruption issue and is
> interested..
What corruption issue? ;)
I'm finding that the corruption happens trivially with your test app, but
apparently doesn'
Btw,
much cleaned-up page tracing patch here, in case anybody cares (and
"test.c" attached, although I don't think it changed since last time).
The test.c output is a bit hard to read at times, since it will give
offsets in bytes as hex (ie "00a77664" means page frame 0a77, and byte
664
On Thu, 28 Dec 2006, Linus Torvalds wrote:
> Ok,
> with the ugly trace capture patch, I've actually captured this corruption
> in action, I think.
>
> I did a full trace of all pages involved in one run, and picked one
> corruption at random:
>
> Chunk 14465 corrupted (0-75) (01423fb4-0
On Thu, 28 Dec 2006, Anton Altaparmakov wrote:
>
> But are chunks 3 and 4 in separate buffer heads? Sorry could not see it
> immediately from the output you showed...
No, this is a 4kB filesystem. A single bh per page.
> It is just that there may be a different cause rather than buffer dirty
On Thu, 28 Dec 2006, David Miller wrote:
>
> What happens when we writeback, to the PTEs?
Not a damn thing.
We clear the PTE's _before_ we even start the write. The writeback does
nothing to them. If the user dirties the page while writeback is in
progress, we'll take the page fault and re-d
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Thu, 28 Dec 2006 14:37:37 -0800 (PST)
> So if we're not losing any dirty bits, what's going on?
What happens when we writeback, to the PTEs?
page_mkclean_file() iterates the VMAs and when it finds a shared
one it goes:
entry = ptep_
Ok,
with the ugly trace capture patch, I've actually captured this corruption
in action, I think.
I did a full trace of all pages involved in one run, and picked one
corruption at random:
Chunk 14465 corrupted (0-75) (01423fb4-01423fff)
Expected 129, got 0
Written as
On Thu, Dec 28, 2006 at 01:24:30PM -0800, Linus Torvalds wrote:
> On Thu, 28 Dec 2006, Linus Torvalds wrote:
> >
> > What we need now is actually looking at the source code, and people who
> > understand the VM, I'm afraid. I'm gathering traces now that I have a good
> > test-case. I'll post my
On Thu, 28 Dec 2006, Linus Torvalds wrote:
>
> What we need now is actually looking at the source code, and people who
> understand the VM, I'm afraid. I'm gathering traces now that I have a good
> test-case. I'll post my trace tools once I've tested that they work, in
> case others want to h
On Thu, 2006-12-28 at 14:39 -0500, Dave Jones wrote:
> On Thu, Dec 28, 2006 at 11:21:21AM -0800, Linus Torvalds wrote:
> >
> >
> > On Thu, 28 Dec 2006, Petri Kaukasoina wrote:
> > > > me up), and that seems to show the corruption going way way back (ie
> going
> > > > back to Linux-2.6.5 a
On Thu, Dec 28, 2006 at 11:21:21AM -0800, Linus Torvalds wrote:
>
>
> On Thu, 28 Dec 2006, Petri Kaukasoina wrote:
> > > me up), and that seems to show the corruption going way way back (ie
> > > going
> > > back to Linux-2.6.5 at least, according to one tester).
> >
> > That was a Fed
On Thu, 28 Dec 2006, Petri Kaukasoina wrote:
> > me up), and that seems to show the corruption going way way back (ie going
> > back to Linux-2.6.5 at least, according to one tester).
>
> That was a Fedora kernel. Has anyone seen the corruption in vanilla 2.6.18
> (or older)?
Well, that was a
On Thu, Dec 28, 2006 at 11:00:46AM -0800, Linus Torvalds wrote:
> And I have a test-program that shows the corruption _much_ easier (at
> least according to my own testing, and that of several reporters that back
> me up), and that seems to show the corruption going way way back (ie going
> back
On Thu, 28 Dec 2006, Marc Haber wrote:
>
> After being up for ten days, I have now encountered the file
> corruption of pkgcache.bin for the first time again. The 256 MB i386
> box is like 26M in swap, is under very moderate load.
>
> I am running plain vanilla 2.6.19.1. Is there a patch that I
On Tue, Dec 19, 2006 at 09:51:49AM +0100, Marc Haber wrote:
> On Sun, Dec 17, 2006 at 09:43:08PM -0800, Andrew Morton wrote:
> > Six hours here of fsx-linux plus high memory pressure on SMP on 1k
> > blocksize ext3, mainline. Zero failures. It's unlikely that this testing
> > would pass, yet peop
On Mon, 18 Dec 2006, Gene Heskett wrote:
>
> What about the mm/rmap.c one liner, in or out?
The one that just removes the "pte_mkclean()"? That's definitely out, it
was just a test-patch to verify that the pte dirty bits seemed to matter
at all (and they do).
Linus
-
To unsubs
On Sat, Dec 16, 2006 at 06:43:10PM +, Martin Michlmayr wrote:
> * Marc Haber <[EMAIL PROTECTED]> [2006-12-09 10:26]:
> > Unfortunately, I am lacking the knowledge needed to do this in an
> > informed way. I am neither familiar enough with git nor do I possess
> > the necessary C powers.
>
> I
On Fri, Dec 22, 2006 at 08:30:06AM -0500, Daniel Drake wrote:
> Marc Haber wrote:
> >After updating to 2.6.19, Debian's apt control file
> >/var/cache/apt/pkgcache.bin corrupts pretty frequently - like in under
> >six hours. In that situation, "aptitude update" segfaults. When I
> >delete the file
Marc Haber wrote:
After updating to 2.6.19, Debian's apt control file
/var/cache/apt/pkgcache.bin corrupts pretty frequently - like in under
six hours. In that situation, "aptitude update" segfaults. When I
delete the file and have apt recreate it, things are fine again for a
few hours before the
On Thu, 21 Dec 2006 14:03:20 +0100
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-12-19 at 09:43 -0800, Linus Torvalds wrote:
> >
> > Btw,
> > here's a totally new tangent on this: it's possible that user code is
> > simply BUGGY.
>
> depmod: BADNESS: written outside isize 22183
ak
On Tue, 2006-12-19 at 09:43 -0800, Linus Torvalds wrote:
>
> Btw,
> here's a totally new tangent on this: it's possible that user code is
> simply BUGGY.
depmod: BADNESS: written outside isize 22183
---
diff --git a/fs/buffer.c b/fs/buffer.c
index d1f1b54..5db9fd9 100644
--- a/fs/buffer.c
+++
Peter Zijlstra wrote:
On Tue, 2006-12-19 at 10:59 -0800, Linus Torvalds wrote:
On Tue, 19 Dec 2006, Linus Torvalds wrote:
here's a totally new tangent on this: it's possible that user code is
simply BUGGY.
I'm sad to say this doesn't trigger :-(
-
To unsubscribe from this l
On Wed, 2006-12-20 at 18:30 +0200, Andrei Popa wrote:
> On Wed, 2006-12-20 at 15:23 +0100, Peter Zijlstra wrote:
> > On Wed, 2006-12-20 at 16:15 +0200, Andrei Popa wrote:
> > > On Wed, 2006-12-20 at 00:42 +0100, Peter Zijlstra wrote:
> > > > On Mon, 2006-12-18 at 12:14 -0800, Linus Torvalds wrote:
On Wed, 2006-12-20 at 15:23 +0100, Peter Zijlstra wrote:
> On Wed, 2006-12-20 at 16:15 +0200, Andrei Popa wrote:
> > On Wed, 2006-12-20 at 00:42 +0100, Peter Zijlstra wrote:
> > > On Mon, 2006-12-18 at 12:14 -0800, Linus Torvalds wrote:
> > >
> > > > OR:
> > > >
> > > > - page_mkclean_one() is s
On Wed, 2006-12-20 at 10:01 +0100, Peter Zijlstra wrote:
> Also, what is this page_test_and_clear_dirty() business, that seems to
> be exclusively s390 btw. However they do seem to need this.
>
> > But the "ptep_get_and_clear() + flush_tlb_page()" sequence should
> > hopefully also work.
>
> Yeah
On Wed, 2006-12-20 at 16:15 +0200, Andrei Popa wrote:
> On Wed, 2006-12-20 at 00:42 +0100, Peter Zijlstra wrote:
> > On Mon, 2006-12-18 at 12:14 -0800, Linus Torvalds wrote:
> >
> > > OR:
> > >
> > > - page_mkclean_one() is simply buggy.
> >
> > GOLD!
> >
> > it seems to work with all this (fu
On Wed, 2006-12-20 at 00:42 +0100, Peter Zijlstra wrote:
> On Mon, 2006-12-18 at 12:14 -0800, Linus Torvalds wrote:
>
> > OR:
> >
> > - page_mkclean_one() is simply buggy.
>
> GOLD!
>
> it seems to work with all this (full diff against current git).
>
> /me rebuilds full kernel to make sure..
> Hmm, should we not flush after clearing the dirty bit? That is, why does
> ptep_clear_flush_dirty() need a flush after clearing that bit? does it
> leak through in the tlb copy?
afaics you need to
1) clear
2) flush
3) check and go to 1) if needed
to be race free.
-
To unsubscribe from th
On Tue, 2006-12-19 at 16:23 -0800, Linus Torvalds wrote:
> Pls test.
Is good. Only s390 remains a question.
Another point, change_protection() also does a cache flush, should we
too?
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index d8a842a..eec8706 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
On Wed, 2006-12-20 at 10:01 +0100, Peter Zijlstra wrote:
> I will try, but I had a look around the different architectures
> implementation of ptep_clear_flush_dirty() and saw that not all do the
> actual flush. So if we go down this road perhaps we should introduce
> another per arch function tha
On Tue, 2006-12-19 at 16:23 -0800, Linus Torvalds wrote:
>
> On Wed, 20 Dec 2006, Peter Zijlstra wrote:
> > On Mon, 2006-12-18 at 12:14 -0800, Linus Torvalds wrote:
> > > OR:
> > >
> > > - page_mkclean_one() is simply buggy.
> >
> > GOLD!
>
> Ok. I was looking at that, and I wondered..
>
> Ho
On 12/20/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Tue, 19 Dec 2006, Linus Torvalds wrote:
>
> here's a totally new tangent on this: it's possible that user code is
> simply BUGGY.
Btw, here's a simpler test-program that actually shows the difference
between 2.6.18 and 2.6.19 in action,
On Wed, 20 Dec 2006, Peter Zijlstra wrote:
> On Mon, 2006-12-18 at 12:14 -0800, Linus Torvalds wrote:
> > OR:
> >
> > - page_mkclean_one() is simply buggy.
>
> GOLD!
Ok. I was looking at that, and I wondered..
However, if that works, then I _think_ the correct sequence is the
following..
T
On Tue, 19 Dec 2006 16:03:49 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 20 Dec 2006, Peter Zijlstra wrote:
>
> > On Tue, 2006-12-19 at 14:58 -0800, Andrew Morton wrote:
> >
> > > Well... we'd need to see (corruption && this-not-triggering) to be sure.
> > >
> > > Pete
On Wed, 20 Dec 2006, Peter Zijlstra wrote:
> On Tue, 2006-12-19 at 14:58 -0800, Andrew Morton wrote:
>
> > Well... we'd need to see (corruption && this-not-triggering) to be sure.
> >
> > Peter, have you been able to trigger the corruption?
>
> Yes; however the mail I send describing that see
On Mon, 2006-12-18 at 12:14 -0800, Linus Torvalds wrote:
> OR:
>
> - page_mkclean_one() is simply buggy.
GOLD!
it seems to work with all this (full diff against current git).
/me rebuilds full kernel to make sure...
reboot...
test... pff the tension...
yay, still good!
Andrei; would you
On Tue, 2006-12-19 at 14:58 -0800, Andrew Morton wrote:
> Well... we'd need to see (corruption && this-not-triggering) to be sure.
>
> Peter, have you been able to trigger the corruption?
Yes; however the mail I send describing that seems to be lost in space.
/me quotes from the send folder:
>
On Wed, 2006-12-20 at 00:06 +0100, Peter Zijlstra wrote:
> On Tue, 2006-12-19 at 14:58 -0800, Andrew Morton wrote:
>
> > Well... we'd need to see (corruption && this-not-triggering) to be sure.
> >
> > Peter, have you been able to trigger the corruption?
>
> Yes; however the mail I send describi
On Tue, 19 Dec 2006 14:51:55 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 19 Dec 2006, Peter Zijlstra wrote:
>
> > On Tue, 2006-12-19 at 10:59 -0800, Linus Torvalds wrote:
> > >
> > > On Tue, 19 Dec 2006, Linus Torvalds wrote:
> > > >
> > > > here's a totally ne
On Tue, 19 Dec 2006, Peter Zijlstra wrote:
> On Tue, 2006-12-19 at 10:59 -0800, Linus Torvalds wrote:
> >
> > On Tue, 19 Dec 2006, Linus Torvalds wrote:
> > >
> > > here's a totally new tangent on this: it's possible that user code is
> > > simply BUGGY.
>
> I'm sad to say this doesn't trig
* Linus Torvalds:
> Now, this should _matter_ only for user processes that are buggy,
> and that have written to the page _before_ extending it with
> ftruncate().
APT seems to properly extend the file before mapping it, by writing a
zero byte at the desired position (creating a hole).
24986 ope
On Tue, 2006-12-19 at 10:59 -0800, Linus Torvalds wrote:
>
> On Tue, 19 Dec 2006, Linus Torvalds wrote:
> >
> > here's a totally new tangent on this: it's possible that user code is
> > simply BUGGY.
I'm sad to say this doesn't trigger :-(
-
To unsubscribe from this list: send the line "unsu
On Mon, 18 Dec 2006, 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
On Tue, 19 Dec 2006, Linus Torvalds wrote:
>
> here's a totally new tangent on this: it's possible that user code is
> simply BUGGY.
Btw, here's a simpler test-program that actually shows the difference
between 2.6.18 and 2.6.19 in action, and why it could explain why a
program like rtorren
Btw,
here's a totally new tangent on this: it's possible that user code is
simply BUGGY.
There is one case where the kernel actually forcibly writes zeroes into a
file: when we're writing a page that straddles the "inode->i_size"
boundary. See the various writepages in fs/buffer.c, they all
On Tue, 19 Dec 2006, Nick Piggin wrote:
>
> Counterexample? Well AFAIKS, the clearing of PG_dirty in ttfb() in
> response to finding all buffers clean is perfectly valid. What makes
> you think otherwise?
If the page really is clean, then why the heck cant' we just clean the
page table bits to
On Tue, 19 Dec 2006, Nick Piggin wrote:
>
> Now I'm not exactly sure how ext3 (or any other) filesystems make use
> of this particular feature of try_to_free_buffers(), but it is clear
> from the comments what it is for. So your patch isn't really a minimal
> fix (ie. it would require an OK from
On Tue, 2006-12-19 at 21:58 +1100, Nick Piggin wrote:
> Peter Zijlstra wrote:
> > On Tue, 2006-12-19 at 02:32 -0800, Andrew Morton wrote:
>
> >>Well it used to be. After 2.6.19 it can do the wrong thing for mapped
> >>pages. But it turns out that we don't feed it mapped pages, apart from
> >>pag
Peter Zijlstra wrote:
On Tue, 2006-12-19 at 02:32 -0800, Andrew Morton wrote:
Well it used to be. After 2.6.19 it can do the wrong thing for mapped
pages. But it turns out that we don't feed it mapped pages, apart from
pagevec_strip() and possibly races against pagefaults.
So how about th
Andrew Morton wrote:
On Tue, 19 Dec 2006 20:56:50 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
I think it could be very likely that indeed the bug is a latent one in
a clear_page_dirty caller, rather than dirty-tracking itself.
The only callers are try_to_free_buffers(), truncate and a few
On Tue, 2006-12-19 at 02:32 -0800, Andrew Morton wrote:
> On Tue, 19 Dec 2006 20:56:50 +1100
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Linus Torvalds wrote:
> >
> > > NOTICE? First you make a BIG DEAL about how dirty bits should never get
> > > lost, but THE VERY SAME FUNCTION actually very
On Tue, 19 Dec 2006 02:32:55 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>
> If a write-fault races with a read-fault and the write-fault loses, we forget
> to mark the page dirty.
No that isn't right, is it. The writer just retakes the fault and
all the right things happen. Ho hum.
-
To
Andrew Morton wrote:
On Tue, 19 Dec 2006 20:56:50 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
Linus Torvalds wrote:
NOTICE? First you make a BIG DEAL about how dirty bits should never get
lost, but THE VERY SAME FUNCTION actually very much on purpose DOES drop
the dirty bit for when it's
On Tue, 19 Dec 2006 20:56:50 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Linus Torvalds wrote:
>
> > NOTICE? First you make a BIG DEAL about how dirty bits should never get
> > lost, but THE VERY SAME FUNCTION actually very much on purpose DOES drop
> > the dirty bit for when it's not in the
Linus Torvalds wrote:
On Tue, 19 Dec 2006, Nick Piggin wrote:
Anyway it has the same issues as the others. See what happens when you
run two test_clear_page_dirty_sync_ptes() consecutively, you still loose
PG_dirty even though the page might actually be dirty.
How can this happen? We'll only
* Marc Haber <[EMAIL PROTECTED]> [2006-12-19 09:51]:
> I do not have a clue about memory management at all, but is it
> possible that you're testing on a box with too much memory? My box has
> only 256 MB, and I used to use mutt with a _huge_ inbox with mutt
> taking somewhat 150 MB. Add spamassass
On Tue, Dec 19, 2006 at 12:24:16AM -0800, Andrew Morton wrote:
> Wow. I didn't expect that, because Mark Haber reported that ext3's
> data=writeback
> fixed it. Maybe he didn't run it for long enough?
My test case is Debian's "aptitude update" running once an hour, and
it was always the same f
On Tue, 2006-12-19 at 10:00 +0100, Peter Zijlstra wrote:
> On Tue, 2006-12-19 at 00:04 -0800, Linus Torvalds wrote:
>
> > Nobody has actually ever explained why "test_clear_page_dirty()" is good
> > at all.
> >
> > - Why is it ever used instead of "clear_page_dirty_for_io()"?
> >
> > - What i
On Tue, 2006-12-19 at 00:04 -0800, Linus Torvalds wrote:
> Nobody has actually ever explained why "test_clear_page_dirty()" is good
> at all.
>
> - Why is it ever used instead of "clear_page_dirty_for_io()"?
>
> - What is the difference?
>
> - Why would you EVER want to clear bits just in t
On Sun, Dec 17, 2006 at 09:43:08PM -0800, Andrew Morton wrote:
> Six hours here of fsx-linux plus high memory pressure on SMP on 1k
> blocksize ext3, mainline. Zero failures. It's unlikely that this testing
> would pass, yet people running normal workloads are able to easily trigger
> failures.
On 12/19/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
Wow. I didn't expect that, because Mark Haber reported that ext3's
data=writeback
fixed it. Maybe he didn't run it for long enough?
I don't think it did fix it for Mark:
http://marc.theaimsgroup.com/?l=linux-kernel&m=116625777306843&w=2
On Tue, 19 Dec 2006 10:05:03 +0200
Andrei Popa <[EMAIL PROTECTED]> wrote:
> > > > Also, it'd be useful if you could determine whether the bug appears with
> > > > the ext2 filesystem: do s/ext3/ext2/ in /etc/fstab, or boot with
> > > > rootfstype=ext2 if it's the root filesystem.
> > >
> I fave
On Tue, 19 Dec 2006, Nick Piggin wrote:
> >
> > Anyway it has the same issues as the others. See what happens when you
> > run two test_clear_page_dirty_sync_ptes() consecutively, you still loose
> > PG_dirty even though the page might actually be dirty.
>
> How can this happen? We'll only test
bits in the PTE's, and never touched them before, we never even realized
that the code that played with PG_dirty was totally insane"
Now, that's just a theory. And yeah, it may be stated a bit provocatively.
It may not be entirely correct. I'm just saying.. maybe it is?
> > > Also, it'd be useful if you could determine whether the bug appears with
> > > the ext2 filesystem: do s/ext3/ext2/ in /etc/fstab, or boot with
> > > rootfstype=ext2 if it's the root filesystem.
> >
I fave file corruption.
-
To unsubscribe from this list: send the line "unsubscribe linux-k
Peter Zijlstra wrote:
On Tue, 2006-12-19 at 15:36 +1100, Nick Piggin wrote:
plain text document attachment (fs-fix.patch)
Index: linux-2.6/fs/buffer.c
===
--- linux-2.6.orig/fs/buffer.c 2006-12-19 15:15:46.0 +1100
+++ lin
On Mon, 2006-12-18 at 11:18 -0800, Linus Torvalds wrote:
> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index d8a842a..3f9061e 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -448,7 +448,7 @@ static int page_mkclean_one(struct page
> > goto unlock;
> >
> > entry = ptep_get_and
On Tue, 19 Dec 2006, Nick Piggin wrote:
>
> 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...
Sure.
> We don't "drop" any data until it has
On Tue, 2006-12-19 at 15:36 +1100, Nick Piggin wrote:
> plain text document attachment (fs-fix.patch)
> Index: linux-2.6/fs/buffer.c
> ===
> --- linux-2.6.orig/fs/buffer.c2006-12-19 15:15:46.0 +1100
> +++ linux-2.6/fs/
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 _b
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?
Linus Torvalds wrote:
On Mon, 18 Dec 2006, Peter Zijlstra wrote:
This should be safe; page_mkclean walks the rmap and flips the pte's
under the pte lock and records the dirty state while iterating.
Concurrent faults will either do set_page_dirty() before we get around
to doing it or vice versa,
> > > If all of test_clear_page_dirty() has been commented out then the page
> > > will
> > > never become clean hence will never fall out of pagecache, so unless
> > > Andrei
> > > is doing a reboot before checking for corruption, perhaps the underlying
> > > data on-disk is incorrect, but we c
On Tue, 19 Dec 2006 03:44:51 +0200
Andrei Popa <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-12-18 at 17:21 -0800, Andrew Morton wrote:
> > On Mon, 18 Dec 2006 16:57:30 -0800 (PST)
> > Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> > > What happens if you only ifdef out that single thing?
> > >
>
On Mon, 2006-12-18 at 16:57 -0800, Linus Torvalds wrote:
>
> On Tue, 19 Dec 2006, Andrei Popa wrote:
> > > >
> > > > nope, no file corruption at all.
> > >
> > > Ok. That's interesting, but I think you actually #ifdef'ed out too
> > > much:
> > >
> > > It was really just the _inner_ "if (mappi
On Mon, 2006-12-18 at 17:21 -0800, Andrew Morton wrote:
> On Mon, 18 Dec 2006 16:57:30 -0800 (PST)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > What happens if you only ifdef out that single thing?
> >
> > The actual page-cleaning functions make sure to only clear the TAG_DIRTY
> > bit _af
On Mon, 18 Dec 2006 16:57:30 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> What happens if you only ifdef out that single thing?
>
> The actual page-cleaning functions make sure to only clear the TAG_DIRTY
> bit _after_ the page has been marked for writeback. Is there some ordering
>
On Monday 18 December 2006 18:48, Andrei Popa wrote:
>On Mon, 2006-12-18 at 14:32 -0800, Linus Torvalds wrote:
>> On Mon, 18 Dec 2006, Andrei Popa wrote:
>> > > This should be fairly easy to test: just change every single ", 1"
>> > > case in the patch to ", 0".
>> > >
>> > > What happens for you i
On Tue, 19 Dec 2006, Andrei Popa wrote:
> > >
> > > nope, no file corruption at all.
> >
> > Ok. That's interesting, but I think you actually #ifdef'ed out too
> > much:
> >
> > It was really just the _inner_ "if (mapping_cap_account_dirty(.."
> > statement that I meant you should remove.
>
On Mon, 2006-12-18 at 16:04 -0800, Linus Torvalds wrote:
>
> On Tue, 19 Dec 2006, Andrei Popa wrote:
> > >
> > > There's exactly two call sites that call "page_mkclean()" (an dthat is
> > > the
> > > only thing in turn that calls "page_mkclean_one()", which we already
> > > determined will cau
On Tue, 19 Dec 2006, Andrei Popa wrote:
>
> the corrupted file has a chink full with zeros
>
> http://193.226.119.62/corruption0.jpg
> http://193.226.119.62/corruption1.jpg
Thanks. Yup, filled with zeroes, and the corruption stops (but does _not_
start) at a page boundary.
That _does_ look v
On Mon, 2006-12-18 at 14:45 -0800, Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Alessandro Suardi wrote:
> >
> > No idea whether this can be a data point or not, but
> > here it goes... my P2P box is about to turn 5 days old
> > while running nonstop one or both of aMule 2.1.3 and
> > BitTorren
On Tue, 19 Dec 2006, Andrei Popa wrote:
> >
> > There's exactly two call sites that call "page_mkclean()" (an dthat is the
> > only thing in turn that calls "page_mkclean_one()", which we already
> > determined will cause the corruption).
> >
> > Can you just TOTALLY DISABLE that case for the
On Mon, 2006-12-18 at 14:32 -0800, Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Andrei Popa wrote:
> > >
> > > This should be fairly easy to test: just change every single ", 1" case
> > > in
> > > the patch to ", 0".
> > >
> > > What happens for you in that case?
> >
> > I have file corrupti
On Mon, 18 Dec 2006, Alessandro Suardi wrote:
>
> No idea whether this can be a data point or not, but
> here it goes... my P2P box is about to turn 5 days old
> while running nonstop one or both of aMule 2.1.3 and
> BitTorrent 4.4.0 on ext3 mounted w/default options
> on both IDE and USB disks.
On Mon, 18 Dec 2006, Andrei Popa wrote:
> >
> > This should be fairly easy to test: just change every single ", 1" case in
> > the patch to ", 0".
> >
> > What happens for you in that case?
>
> I have file corruption.
Magic. And btw, _thanks_ for being such a great tester.
So now I have one m
On Monday 18 December 2006 15:41, Linus Torvalds wrote:
>On Mon, 18 Dec 2006, Linus Torvalds wrote:
>> But at the same time, it's interesting that it still happens when we
>> try to re-add the dirty bit. That would tell me that it's one of two
>> cases:
>
>Forget that. There's a third case, which i
On 12/18/06, Andrei Popa <[EMAIL PROTECTED]> wrote:
On Mon, 2006-12-18 at 12:41 -0800, Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Linus Torvalds wrote:
> >
> > But at the same time, it's interesting that it still happens when we try
> > to re-add the dirty bit. That would tell me that it's on
On Mon, 2006-12-18 at 12:14 -0800, Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Andrei Popa wrote:
> >
> > I dropped that patch and added WARN_ON(1), the unified patch is
> > attached.
> >
> > I got corruption: "Hash check on download completion found bad chunks,
> > consider using "safe_sync"
On Mon, 18 Dec 2006 12:14:35 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> OR:
>
> - page_mkclean_one() is simply buggy.
>
> And I'm starting to wonder about the second case. But it all LOOKS really
> fine - I can't see anything wrong there (it uses the extremely
> conservative "pte
On Mon, 2006-12-18 at 12:41 -0800, Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Linus Torvalds wrote:
> >
> > But at the same time, it's interesting that it still happens when we try
> > to re-add the dirty bit. That would tell me that it's one of two cases:
>
> Forget that. There's a third c
On Mon, 18 Dec 2006, Linus Torvalds wrote:
>
> But at the same time, it's interesting that it still happens when we try
> to re-add the dirty bit. That would tell me that it's one of two cases:
Forget that. There's a third case, which is much more likely:
- Andrew's patch had a ", 1" where i
On Mon, 18 Dec 2006, Andrei Popa wrote:
>
> I dropped that patch and added WARN_ON(1), the unified patch is
> attached.
>
> I got corruption: "Hash check on download completion found bad chunks,
> consider using "safe_sync"."
Ok. That is actually _very_ interesting.
It's interesting because (
On Mon, 2006-12-18 at 11:18 -0800, Linus Torvalds wrote:
>
> On Mon, 18 Dec 2006, Andrei Popa wrote:
> >
> > I applied Linus patch, Andrew patch, Peter Zijlstra patches(the last
> > two). All unified patch is attached. I tested and I have no corruption.
>
> That wasn't very interesting, because
On Mon, 18 Dec 2006, Andrei Popa wrote:
>
> I applied Linus patch, Andrew patch, Peter Zijlstra patches(the last
> two). All unified patch is attached. I tested and I have no corruption.
That wasn't very interesting, because you also had the patch that just
disabled "page_mkclean_one()" entire
1 - 100 of 153 matches
Mail list logo
