Andrew Morton wrote:
On Mon, 18 Dec 2006 18:22:42 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
Yes I could believe it the corruption is caused by something else
completely.
Think so. We do have a problem here, but only on threaded apps, I believe.
rtorrent doesn't appear to be threaded, and
OK, I'll try this on a ext3 box. BTW, what data mode are you using ext3
in?
ordered
Also, for testings sake, could you give this a go:
It's a total hack but I guess worth testing.
---
mm/rmap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index:
On Monday 18 December 2006 05:49, Andrei Popa wrote:
OK, I'll try this on a ext3 box. BTW, what data mode are you using
ext3 in?
ordered
Also, for testings sake, could you give this a go:
It's a total hack but I guess worth testing.
---
mm/rmap.c |2 +-
1 file changed, 1
On Mon, 2006-12-18 at 10:24 -0500, Gene Heskett wrote:
On Monday 18 December 2006 05:49, Andrei Popa wrote:
OK, I'll try this on a ext3 box. BTW, what data mode are you using
ext3 in?
ordered
Also, for testings sake, could you give this a go:
It's a total hack but I guess worth
On Monday 18 December 2006 10:32, Peter Zijlstra wrote:
[...]
I've not run a torrent app here recently. Should this patch be
applied to a plain 2.6-20-rc1 before I do run azureas or similar apps?
depends on what the blue frog does, if it uses MAP_SHARED like rtorrent
does then yeah, probably.
On Sun, 2006-12-17 at 15:40 -0800, Andrew Morton wrote:
On Sun, 17 Dec 2006 15:39:32 +0200
Andrei Popa [EMAIL PROTECTED] wrote:
I was mistaken, I'm still having file corruption with rtorrent.
Well I'm not very optimistic, but if people could try this, please...
From: Andrew
Andrei,
could you try Peter's patch (on top of Andrew's patch - it depends on
it, and wouldn't work on an unmodified -git kernel, but add the WARN_ON()
I mention in this email? You seem to be able to reproduce this easily..
Thanks)
On Mon, 18 Dec 2006, Peter Zijlstra wrote:
This should be
On Mon, 2006-12-18 at 10:03 -0800, Linus Torvalds wrote:
Andrei,
could you try Peter's patch (on top of Andrew's patch - it depends on
it, and wouldn't work on an unmodified -git kernel, but add the WARN_ON()
I mention in this email? You seem to be able to reproduce this easily..
Thanks)
On Mon, 18 Dec 2006, Peter Zijlstra wrote:
Or maybe the WARN_ON() just points out _why_ somebody would want to do
something this insane. Right now I just can't see why it's a valid thing
to do.
Maybe, but I think Nick's mail here:
http://lkml.org/lkml/2006/12/18/59
shows a
(On that note: Andrei - if you do test this out, I'd suggest applying my
patch too - the one that you already tested. It won't apply cleanly on top
of Andrew's patch, but it should be trivial to apply by hand, since you
really just want to remove the whole if (ret) {...} sequence. I
On Mon, 2006-12-18 at 21:04 +0200, Andrei Popa 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_clear(mm, address,
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() entirely:
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 you also
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 (a) the
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 it
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 case,
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
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.
Ok. That is
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 one of two
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 is much
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 more thng for
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. Zero
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 corruption.
Magic. And btw,
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: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
BitTorrent 4.4.0 on
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 very
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 cause the corruption).
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.
Can you try that
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 in that case?
I
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 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 _after_ the
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 (mapping_cap_account_dirty(..
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?
The actual
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 can't see it.
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
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 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
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
+++
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 been
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_clear(mm,
On Sun, 17 Dec 2006 23:16:17 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > out:
> > if (buffers_to_free) {
> > struct buffer_head *bh = buffers_to_free;
>
> This will (at least) cause truncate to do peculiar things.
> do_invalidatepage() runs discard_buffer() against the
On Sun, 17 Dec 2006 21:50:43 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 18 Dec 2006, Nick Piggin wrote:
> >
> > I can't see how that's exactly a problem -- so long as the page does not
> > get reclaimed (it won't, because we have a ref on it) then all that matters
> >
On Mon, 18 Dec 2006, Nick Piggin wrote:
>
> I can't see how that's exactly a problem -- so long as the page does not
> get reclaimed (it won't, because we have a ref on it) then all that matters
> is that the page eventually gets marked dirty.
But the point being that "try_to_free_buffers()"
On Mon, 18 Dec 2006 15:51:52 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> I think the problem Andrew identified is real.
I don't. In fact I don't think I described any problem (well, I tried to,
but then I contradicted myself).
Six hours here of fsx-linux plus high memory pressure on SMP on
Linus Torvalds wrote:
[ Replying to myself - a sure sign that I don't get out enough ]
On Sun, 17 Dec 2006, Linus Torvalds wrote:
So I don't actually see any serialization at all that would keep a random
page from being paged back in.
We do actually serialize, but we do it _after_ the page
[ Replying to myself - a sure sign that I don't get out enough ]
On Sun, 17 Dec 2006, Linus Torvalds wrote:
>
> So I don't actually see any serialization at all that would keep a random
> page from being paged back in.
We do actually serialize, but we do it _after_ the page has already been
On Sun, 17 Dec 2006, Linus Torvalds wrote:
>
> So we should probably do a "wait_for_page()" in do_no_page()?
>
> Or maybe only do it for write accesses (since we don't really care about
> getting mapped readably)? If so, we need to do it in the write case of
> do_no_page() _and_ in the
On Sun, 17 Dec 2006, Andrew Morton wrote:
>
> From my quick reading, all callers of try_to_free_buffers() have already
> unmapped the page from pagetables, and given that the reported ext3 corruption
> happens on uniprocessor, non-preempt kernels, I doubt if this patch will fix
> things.
Hmm.
On Sun, 17 Dec 2006, Andrew Morton wrote:
>
> So this patch instead arranges for clear_page_dirty() to not clean the pte's
> when it is called on the try_to_free_buffers() path.
No. This is wrong.
It's wrong exactly because it now _breaks_ the whole thing that the 2.6.19
PG_dirty changes
On Sun, 17 Dec 2006 15:39:32 +0200
Andrei Popa <[EMAIL PROTECTED]> wrote:
> I was mistaken, I'm still having file corruption with rtorrent.
>
Well I'm not very optimistic, but if people could try this, please...
From: Andrew Morton <[EMAIL PROTECTED]>
try_to_free_buffers() clears the page's
> On Sat, 16 Dec 2006, 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 wonder
I was mistaken, I'm still having file corruption with rtorrent.
On Sun, 2006-12-17 at 04:06 -0800, Andrew Morton wrote:
> On Sun, 17 Dec 2006 02:13:18 +0200
> Andrei Popa <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> > I had filesystem data corruption with rtorrent with 2.6.19.
> > I tried recent
ierdnac ~ # uname -a
Linux ierdnac 2.6.20-rc1 #1 SMP PREEMPT Sun Dec 17 01:52:28 EET 2006
i686 Genuine Intel(R) CPU T2050 @ 1.60GHz GenuineIntel
GNU/Linux
On Sun, 2006-12-17 at 04:06 -0800, Andrew Morton wrote:
> On Sun, 17 Dec 2006 02:13:18 +0200
> Andrei Popa <[EMAIL PROTECTED]>
On Sun, Dec 17, 2006 at 04:06:20AM -0800, Andrew Morton wrote:
> I'd be really surprised if this was all due to a race though. Is everyone
> who has observed this problem running SMP and/or premptible kernels?
Linux torres 2.6.19.1-zgsrv #1 SMP PREEMPT Wed Dec 13 01:31:27 UTC 2006 i686
On Sun, 17 Dec 2006 02:13:18 +0200
Andrei Popa <[EMAIL PROTECTED]> wrote:
> Hello,
> I had filesystem data corruption with rtorrent with 2.6.19.
> I tried recent git with Peter Zijlstra patch
> http://lkml.org/lkml/2006/12/16/144 and it seems that the problem is
> fixed.
>
oh crap, I'd
On Sat, 16 Dec 2006 19:31:25 +0100
Florian Weimer <[EMAIL PROTECTED]> wrote:
> * Marc Haber:
>
> > After updating to 2.6.19, Debian's apt control file
> > /var/cache/apt/pkgcache.bin corrupts pretty frequently - like in under
> > six hours.
>
> I've seen that with Debian's 2.6.18 kernels as
On Sat, 16 Dec 2006 19:31:25 +0100
Florian Weimer [EMAIL PROTECTED] wrote:
* Marc Haber:
After updating to 2.6.19, Debian's apt control file
/var/cache/apt/pkgcache.bin corrupts pretty frequently - like in under
six hours.
I've seen that with Debian's 2.6.18 kernels as well. Perhaps
On Sun, 17 Dec 2006 02:13:18 +0200
Andrei Popa [EMAIL PROTECTED] wrote:
Hello,
I had filesystem data corruption with rtorrent with 2.6.19.
I tried recent git with Peter Zijlstra patch
http://lkml.org/lkml/2006/12/16/144 and it seems that the problem is
fixed.
oh crap, I'd forgotten that
On Sun, Dec 17, 2006 at 04:06:20AM -0800, Andrew Morton wrote:
I'd be really surprised if this was all due to a race though. Is everyone
who has observed this problem running SMP and/or premptible kernels?
Linux torres 2.6.19.1-zgsrv #1 SMP PREEMPT Wed Dec 13 01:31:27 UTC 2006 i686
GNU/Linux
ierdnac ~ # uname -a
Linux ierdnac 2.6.20-rc1 #1 SMP PREEMPT Sun Dec 17 01:52:28 EET 2006
i686 Genuine Intel(R) CPU T2050 @ 1.60GHz GenuineIntel
GNU/Linux
On Sun, 2006-12-17 at 04:06 -0800, Andrew Morton wrote:
On Sun, 17 Dec 2006 02:13:18 +0200
Andrei Popa [EMAIL PROTECTED] wrote:
I was mistaken, I'm still having file corruption with rtorrent.
On Sun, 2006-12-17 at 04:06 -0800, Andrew Morton wrote:
On Sun, 17 Dec 2006 02:13:18 +0200
Andrei Popa [EMAIL PROTECTED] wrote:
Hello,
I had filesystem data corruption with rtorrent with 2.6.19.
I tried recent git with
On Sat, 16 Dec 2006, 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 wonder if what you're
On Sun, 17 Dec 2006 15:39:32 +0200
Andrei Popa [EMAIL PROTECTED] wrote:
I was mistaken, I'm still having file corruption with rtorrent.
Well I'm not very optimistic, but if people could try this, please...
From: Andrew Morton [EMAIL PROTECTED]
try_to_free_buffers() clears the page's dirty
On Sun, 17 Dec 2006, Andrew Morton wrote:
So this patch instead arranges for clear_page_dirty() to not clean the pte's
when it is called on the try_to_free_buffers() path.
No. This is wrong.
It's wrong exactly because it now _breaks_ the whole thing that the 2.6.19
PG_dirty changes were
On Sun, 17 Dec 2006, Andrew Morton wrote:
From my quick reading, all callers of try_to_free_buffers() have already
unmapped the page from pagetables, and given that the reported ext3 corruption
happens on uniprocessor, non-preempt kernels, I doubt if this patch will fix
things.
Hmm. One
On Sun, 17 Dec 2006, Linus Torvalds wrote:
So we should probably do a wait_for_page() in do_no_page()?
Or maybe only do it for write accesses (since we don't really care about
getting mapped readably)? If so, we need to do it in the write case of
do_no_page() _and_ in the do_wp_page()
[ Replying to myself - a sure sign that I don't get out enough ]
On Sun, 17 Dec 2006, Linus Torvalds wrote:
So I don't actually see any serialization at all that would keep a random
page from being paged back in.
We do actually serialize, but we do it _after_ the page has already been
Linus Torvalds wrote:
[ Replying to myself - a sure sign that I don't get out enough ]
On Sun, 17 Dec 2006, Linus Torvalds wrote:
So I don't actually see any serialization at all that would keep a random
page from being paged back in.
We do actually serialize, but we do it _after_ the page
On Mon, 18 Dec 2006 15:51:52 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
I think the problem Andrew identified is real.
I don't. In fact I don't think I described any problem (well, I tried to,
but then I contradicted myself).
Six hours here of fsx-linux plus high memory pressure on SMP on 1k
On Mon, 18 Dec 2006, Nick Piggin wrote:
I can't see how that's exactly a problem -- so long as the page does not
get reclaimed (it won't, because we have a ref on it) then all that matters
is that the page eventually gets marked dirty.
But the point being that try_to_free_buffers() marks
On Sun, 17 Dec 2006 21:50:43 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Mon, 18 Dec 2006, Nick Piggin wrote:
I can't see how that's exactly a problem -- so long as the page does not
get reclaimed (it won't, because we have a ref on it) then all that matters
is that the
On Sun, 17 Dec 2006 23:16:17 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
out:
if (buffers_to_free) {
struct buffer_head *bh = buffers_to_free;
This will (at least) cause truncate to do peculiar things.
do_invalidatepage() runs discard_buffer() against the dirty page
Hello,
I had filesystem data corruption with rtorrent with 2.6.19.
I tried recent git with Peter Zijlstra patch
http://lkml.org/lkml/2006/12/16/144 and it seems that the problem is
fixed.
Please CC as I am not subscribed to lkml.
Andrei
-
To unsubscribe from this list: send the line
On Sat, 16 Dec 2006, Peter Zijlstra wrote:
> Moving the cleaning of the page out from under the private_lock opened
> up a window where newly attached buffer might still see the page dirty
> status and were thus marked (incorrectly) dirty themselves; resulting in
> filesystem data corruption.
I'm
On Sat, 2006-12-16 at 19:18 +, Hugh Dickins wrote:
> On Sat, 16 Dec 2006, 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
On Sat, 16 Dec 2006, 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 wonder if what
* Marc Haber:
> After updating to 2.6.19, Debian's apt control file
> /var/cache/apt/pkgcache.bin corrupts pretty frequently - like in under
> six hours.
I've seen that with Debian's 2.6.18 kernels as well. Perhaps it's
related to this Debian bug?
* 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 wonder if what you're seein is related to
http://lkml.org/lkml/2006/12/16/73
On Fri, Dec 15, 2006 at 10:30:34AM +0100, Marc Haber wrote:
> Additionally, updating to 2.6.19.1
> allowed me to remove data=writeback without the issue re-surfacing. I
> suspect that the issue is fixed now.
Unfortunately, this suspicion proved wrong when the file was corrupted
again this
On Fri, Dec 15, 2006 at 10:30:34AM +0100, Marc Haber wrote:
Additionally, updating to 2.6.19.1
allowed me to remove data=writeback without the issue re-surfacing. I
suspect that the issue is fixed now.
Unfortunately, this suspicion proved wrong when the file was corrupted
again this morning.
* 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 wonder if what you're seein is related to
http://lkml.org/lkml/2006/12/16/73
You
* Marc Haber:
After updating to 2.6.19, Debian's apt control file
/var/cache/apt/pkgcache.bin corrupts pretty frequently - like in under
six hours.
I've seen that with Debian's 2.6.18 kernels as well. Perhaps it's
related to this Debian bug?
On Sat, 16 Dec 2006, 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 wonder if what you're seein is
On Sat, 2006-12-16 at 19:18 +, Hugh Dickins wrote:
On Sat, 16 Dec 2006, 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
On Sat, 16 Dec 2006, Peter Zijlstra wrote:
Moving the cleaning of the page out from under the private_lock opened
up a window where newly attached buffer might still see the page dirty
status and were thus marked (incorrectly) dirty themselves; resulting in
filesystem data corruption.
I'm not
Hello,
I had filesystem data corruption with rtorrent with 2.6.19.
I tried recent git with Peter Zijlstra patch
http://lkml.org/lkml/2006/12/16/144 and it seems that the problem is
fixed.
Please CC as I am not subscribed to lkml.
Andrei
-
To unsubscribe from this list: send the line unsubscribe
On Thu, Dec 14, 2006 at 01:03:41PM +0100, Jan Kara wrote:
> > On Sat, Dec 09, 2006 at 11:47:58AM +0100, Jan Kara wrote:
> > > In the mean time
> > > does mounting the filesystem with data=writeback help?
> >
> > I have now nine hours uptime with data=writeback, and the file is
> > still OK.
On Thu, Dec 14, 2006 at 01:03:41PM +0100, Jan Kara wrote:
On Sat, Dec 09, 2006 at 11:47:58AM +0100, Jan Kara wrote:
In the mean time
does mounting the filesystem with data=writeback help?
I have now nine hours uptime with data=writeback, and the file is
still OK. Looks good.
> On Sat, Dec 09, 2006 at 11:47:58AM +0100, Jan Kara wrote:
> > In the mean time
> > does mounting the filesystem with data=writeback help?
>
> I have now nine hours uptime with data=writeback, and the file is
> still OK. Looks good.
>
> By this posting, I'm going to invoke murphy, so I'll
On Sat, Dec 09, 2006 at 11:47:58AM +0100, Jan Kara wrote:
> In the mean time
> does mounting the filesystem with data=writeback help?
I have now nine hours uptime with data=writeback, and the file is
still OK. Looks good.
By this posting, I'm going to invoke murphy, so I'll report again
On Sun, Dec 10, 2006 at 12:46:01AM +0100, Mike Galbraith wrote:
> On Fri, 2006-12-08 at 17:42 +0100, Marc Haber wrote:
> > On Fri, Dec 08, 2006 at 10:38:12AM +0900, Fernando Luis Vázquez Cao wrote:
> > > Does the patch below help?
> > >
> > >
On Sun, Dec 10, 2006 at 12:46:01AM +0100, Mike Galbraith wrote:
On Fri, 2006-12-08 at 17:42 +0100, Marc Haber wrote:
On Fri, Dec 08, 2006 at 10:38:12AM +0900, Fernando Luis Vázquez Cao wrote:
Does the patch below help?
http://marc.theaimsgroup.com/?l=linux-ext4m=116483980823714w=4
On Sat, Dec 09, 2006 at 11:47:58AM +0100, Jan Kara wrote:
In the mean time
does mounting the filesystem with data=writeback help?
I have now nine hours uptime with data=writeback, and the file is
still OK. Looks good.
By this posting, I'm going to invoke murphy, so I'll report again
On Fri, 2006-12-08 at 17:42 +0100, Marc Haber wrote:
> On Fri, Dec 08, 2006 at 10:38:12AM +0900, Fernando Luis Vázquez Cao wrote:
> > Does the patch below help?
> >
> > http://marc.theaimsgroup.com/?l=linux-ext4=116483980823714=4
>
> No, pkgcache.bin still getting corrupted within two hours of
> On Fri, Dec 08, 2006 at 10:38:12AM +0900, Fernando Luis Vázquez Cao wrote:
> > Does the patch below help?
> >
> > http://marc.theaimsgroup.com/?l=linux-ext4=116483980823714=4
>
> No, pkgcache.bin still getting corrupted within two hours of using
> 2.6.19.
Hmm, interesting. I'll try to
On Thu, Dec 07, 2006 at 11:50:37AM -0500, Phillip Susi wrote:
> Marc Haber wrote:
> >I went back to 2.6.18.3 to debug this, and the system ran for three
> >days without problems and without corrupting
> >/var/cache/apt/pkgcache.bin. After booting 2.6.19 again, it took three
> >hours for the file
On Thu, Dec 07, 2006 at 11:50:37AM -0500, Phillip Susi wrote:
Marc Haber wrote:
I went back to 2.6.18.3 to debug this, and the system ran for three
days without problems and without corrupting
/var/cache/apt/pkgcache.bin. After booting 2.6.19 again, it took three
hours for the file corruption
On Fri, Dec 08, 2006 at 10:38:12AM +0900, Fernando Luis Vázquez Cao wrote:
Does the patch below help?
http://marc.theaimsgroup.com/?l=linux-ext4m=116483980823714w=4
No, pkgcache.bin still getting corrupted within two hours of using
2.6.19.
Hmm, interesting. I'll try to reproduce the
On Fri, 2006-12-08 at 17:42 +0100, Marc Haber wrote:
On Fri, Dec 08, 2006 at 10:38:12AM +0900, Fernando Luis Vázquez Cao wrote:
Does the patch below help?
http://marc.theaimsgroup.com/?l=linux-ext4m=116483980823714w=4
No, pkgcache.bin still getting corrupted within two hours of using
On Fri, Dec 08, 2006 at 10:38:12AM +0900, Fernando Luis Vázquez Cao wrote:
> Does the patch below help?
>
> http://marc.theaimsgroup.com/?l=linux-ext4=116483980823714=4
No, pkgcache.bin still getting corrupted within two hours of using
2.6.19.
Greetings
Marc, back to 2.6.18.3 for the time being
201 - 300 of 305 matches
Mail list logo
