From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Oleksij Rempel <linux@rempel-privat.de>
Cc: linux-ext4@vger.kernel.org
Subject: Re: What is status of metadata_csum
Date: Fri, 17 Jan 2014 12:58:19 -0800 [thread overview]
Message-ID: <20140117205819.GM9229@birch.djwong.org> (raw)
In-Reply-To: <52D98ED7.8050608@rempel-privat.de>
On Fri, Jan 17, 2014 at 09:13:11PM +0100, Oleksij Rempel wrote:
> Am 17.01.2014 20:21, schrieb Darrick J. Wong:
> > On Fri, Jan 17, 2014 at 11:39:07AM +0100, Oleksij Rempel wrote:
> >> Am 17.01.2014 09:18, schrieb Oleksij Rempel:
> >>> Am 17.01.2014 03:00, schrieb Darrick J. Wong:
> >>>> On Thu, Jan 16, 2014 at 11:57:20AM +0100, Oleksij Rempel wrote:
> >>>>> What is metadata_csum status?
> >>>>>
> >>>>> i see there are benchmark updates on wiki page, but no updates for
> >>>>> e2fsprogs. 1.43-WIP seems to be really old.
> >>>>
> >>>> Still waiting for 1.43. I don't know if there are early adopters running
> >>>> 1.43-WIP without complaint, or if simply nobody's using it at all. :/
> >>>
> >>> I didn't tested current master.git - my bad. It is not outdated :)
> >>>
> >>> Beside, the wiki should be corrected. If you enable 64bit, it will need
> >>> extents too.
> >>>
> >>> Are there any existing tools for error injection for file systems?
> >>> Random read error from libata or silent data corruptions?
> >>>
> >>
> >> I was playing with metadata_csum trying to kill my system and now i have
> >> some questions:
> >>
> >> first the test:
> >> #find block number
> >> sudo ./debugfs/debugfs -R "imap <3991825>" /dev/sdf1
> >>
> >> #copy block
> >> sudo dd if=/dev/sdf1 bs=4K count=1 skip=15958163 of=corrupt_block.bin
> >>
> >> #change one byte
> >> ghex corrupt_block.bin
> >>
> >> #kill inode
> >> sudo dd of=/dev/sdf1 bs=4K count=1 seek=15958163 if=corrupt_block.bin
> >>
> >> sudo ./debugfs/debugfs -R "stat <3991825>" /dev/sdf1
> >> #stat: Inode checksum does not match inode while reading inode 3991825
> >>
> >> so, inode is corrupt:
> >> - ext4 can detect inode corruption. Great work! I like it :)
> >> - in this case file will not be shown by Nautilus.
> >> - ls will show some thing like this:
> >>
> >> 4130898 drwx------ 8 oleksij oleksij 4096 Jan 17 09:31 Bilder
> >> ? -????????? ? ? ? ? ?
> >> ich-einfach_unverbesserlich_2.mkv
> >> 3991826 -rw-rw-r-- 1 oleksij oleksij 622038707 Jan 17 11:12 igor.mkv
> >> 3989506 drwxr-xr-x 26 oleksij oleksij 4096 Okt 9 23:11 linux
> >>
> >> it means, i know there is some thing wrong, but i do not know which inode
> >
> > Unfortunately, either the whole stat call succeeds or it doesn't. Your best
> > bet to find the inode is:
> > debugfs -n -R 'stat /path/within/fs' /dev/sdXXX
>
> Ok, looks like user space apps should handle errors in different whey. I
> mean some thing like, show notification about probable FS errors and so on.
AIX has ECORRUPT; maybe we should define that for the kernel/glibc?
> >> - If fs is not fixed, file is lost? are blocks still allocated to this
> >> inode?
> >
> > Yes, the blocks are still allocated.
> >
> >> - debufs will not allow me to edit inode corrupt inode.
> >
> > debugfs -n (disables checksum verification)
> >
> >> - If i run fsck -y file is lost. Most user wont be able to recover it.
> >
> > If you answer 'n' to the first prompt about the checksum failure, e2fsck will
> > check the rest of the inode. If no other problems are found, it'll ask to
> > correct the checksum.
> >
> > I've wondered if perhaps e2fsck ought to do something like this when there's a
> > checksum problem:
> >
> > 1. If the user didn't prohibit clearing the inode as the first potential
> > action, ask if e2fsck should just clear the inode.
> > 2. If not, run the regular checks.
> > 3. If there's still a checksum error, ask to fix the checksum.
> > 4. If the user doesn't want to fix it, ask to clear the inode.
>
> sounds good.
>
> > iow, e2fsck --verify-checksums-last /dev/sdXX
>
> this mean?
It would be a new flag to change the fsck behavior.
> PS: More testing results from today. GRUB fails to install if
> metadata_csum enabled. Should it be reported to GRUB devs?
Yes, please report the bug to them. metadata_csum is a ROCOMPAT feature, which
means that grub will need to learn about checksums if it wants to do anything
other than rewrites of existing file blocks.
--D
next prev parent reply other threads:[~2014-01-17 20:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 10:57 What is status of metadata_csum Oleksij Rempel
2014-01-17 2:00 ` Darrick J. Wong
2014-01-17 8:18 ` Oleksij Rempel
2014-01-17 10:39 ` Oleksij Rempel
2014-01-17 19:21 ` Darrick J. Wong
2014-01-17 20:13 ` Oleksij Rempel
2014-01-17 20:58 ` Darrick J. Wong [this message]
2014-01-17 22:32 ` Oleksij Rempel
2014-01-17 18:54 ` Darrick J. Wong
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=20140117205819.GM9229@birch.djwong.org \
--to=darrick.wong@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux@rempel-privat.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).