All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Aioanei Rares <krnl.list@gmail.com>,
	linux-ext4@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Mild filesystem corruption on ext4 (no journal)
Date: Fri, 05 Jun 2009 22:32:37 +0100	[thread overview]
Message-ID: <4A298EF5.9000504@tuffmail.co.uk> (raw)
In-Reply-To: <4A29601F.3070802@redhat.com>

Eric Sandeen wrote:
> Alan Jenkins wrote:
>   
>> Eric Sandeen wrote:
>>     
>
>   
>>> Maybe you could try some things in your shutdown script, such as
>>> explicitly fsyncing the file, or bmapping it with filefrag, or dropping
>>> caches and rereading it... see what the state is just before the
>>> shutdown compared to after the reboot.
>>>
>>> -Eric
>>>   
>>>       
>> Dropping caches (and running sync first) had no effect on the result of 
>> md5sum.  Hopefully that narrows it down a bit.
>>     
>
> And did the reread after dropping caches have the right data?
>   

Yes.

> Did the block numbers reported by filefrag -v change post-boot?
>   

Oh, I didn't understand that's what you were asking for.

The bug report Ted linked to says it's (most likely) a writeback issue.  
In which case I think the block numbers won't change.  I'll check 
tomorrow, and follow-up if it turns up any unexpected result.

There's also speculation that it's a core kernel issue, something that 
changed since 2.6.26.  Perhaps that explains how remount-ro + sync + 
drop_caches can leave the correct data sitting in the pagecache, without 
either writing it to disk or dropping it.

Thanks
Alan

  reply	other threads:[~2009-06-05 21:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-05 10:49 Mild filesystem corruption on ext4 (no journal) Alan Jenkins
2009-06-05 14:40 ` Aioanei Rares
2009-06-05 14:49   ` Alan Jenkins
2009-06-05 15:20     ` Eric Sandeen
2009-06-05 16:43       ` Alan Jenkins
2009-06-05 16:51         ` Kay Sievers
2009-06-05 16:51           ` Kay Sievers
2009-06-05 21:42           ` Alan Jenkins
2009-06-06  4:17             ` Henrique de Moraes Holschuh
2009-06-05 18:12         ` Eric Sandeen
2009-06-05 21:32           ` Alan Jenkins [this message]
2009-06-05 22:02             ` Eric Sandeen
2009-06-05 18:01   ` Theodore Tso
2009-06-05 21:34     ` Alan Jenkins
2009-06-05 21:34       ` Alan Jenkins
2009-06-05 21:42     ` Curt Wohlgemuth
2009-06-05 21:42       ` Curt Wohlgemuth
2009-06-09  4:15       ` Michael Rubin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A298EF5.9000504@tuffmail.co.uk \
    --to=alan-jenkins@tuffmail.co.uk \
    --cc=krnl.list@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.