From: Gregory Farnum <gregory.farnum@dreamhost.com>
To: Fyodor Ustinov <ufm@ufm.su>
Cc: Sage Weil <sage@newdream.net>,
Henry Chang <henry.cy.chang@gmail.com>,
ceph-devel@vger.kernel.org
Subject: Re: It's not a bug of ceph, but
Date: Thu, 14 Apr 2011 10:08:29 -0700 [thread overview]
Message-ID: <2B548686BA1D4CDD996A068F689C1B0A@gmail.com> (raw)
In-Reply-To: <4DA5FA4C.7030205@ufm.su>
On Wednesday, April 13, 2011 at 12:32 PM, Fyodor Ustinov wrote:
On this kernel (2.6.38-8-server ubuntu 11.04) i have trouble with ext4 also.
>
> I mount fresh ceph partition on client, test by bonnie++, unmount, stop
> ceph cluster, umount osd ext4 partition and forced fsck this partition.
>
> Mount string on OSD:
>
> /dev/md127 /mfs auto rw,noatime,nodiratime,async,noexec,nodev,user_xattr 0 0
>
> No any messages in kernel log. But:
>
> root@stc1:/home/ufm# umount /mfs
> root@stc1:/home/ufm# fsck /dev/md127
> fsck from util-linux-ng 2.17.2
> e2fsck 1.41.14 (22-Dec-2010)
> /dev/md127: clean, 29779/59834368 files, 3887821/239314496 blocks
>
> root@stc1:/home/ufm# fsck -f /dev/md127
> fsck from util-linux-ng 2.17.2
> e2fsck 1.41.14 (22-Dec-2010)
> Pass 1: Checking inodes, blocks, and sizes
> Inode 4456487, i_blocks is 8200, should be 8208. Fix<y>? yes
>
> Inode 4456499, i_blocks is 8208, should be 8200. Fix<y>? yes
>
> Inode 4456549, i_blocks is 24, should be 16. Fix<y>? yes
>
> Inode 4456579, i_blocks is 24, should be 16. Fix<y>? yes
>
> Inode 4456580, i_blocks is 8, should be 16. Fix<y>? yes
>
> Inode 4456591, i_blocks is 8, should be 16. Fix<y>? yes
>
> Inode 4456601, i_blocks is 24, should be 16. Fix<y>? /dev/md127: e2fsck
> canceled.
>
> /dev/md127: ***** FILE SYSTEM WAS MODIFIED *****
>
> May be md. I test now without md.
So Ceph worked fine and you got no complaints until you ran fsck? That's odd but I don't think we've gotten any reports of data corruption or anything with Ceph on ext4. You should probably report this to the ext4 devs as Ceph doesn't do anything that should be able to break that stuff, but it does use some less-common code paths in a lot of filesystems.
-Greg
prev parent reply other threads:[~2011-04-14 17:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-13 10:57 It's not a bug of ceph, but Fyodor Ustinov
2011-04-13 14:44 ` Henry Chang
2011-04-13 16:22 ` Sage Weil
2011-04-13 19:32 ` Fyodor Ustinov
2011-04-14 0:09 ` Fyodor Ustinov
2011-04-14 17:08 ` Gregory Farnum [this message]
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=2B548686BA1D4CDD996A068F689C1B0A@gmail.com \
--to=gregory.farnum@dreamhost.com \
--cc=ceph-devel@vger.kernel.org \
--cc=henry.cy.chang@gmail.com \
--cc=sage@newdream.net \
--cc=ufm@ufm.su \
/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.