From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Dmitry Monakhov <dmonakhov@openvz.org>,
linux-ext4@vger.kernel.org, wenqing.lz@taobao.com
Subject: Re: [PATCH 2/2] ext4: fix cpu_vs_disk conversions
Date: Wed, 3 Apr 2013 21:04:43 +0800 [thread overview]
Message-ID: <20130403130443.GA16014@gmail.com> (raw)
In-Reply-To: <20130403123317.GD7741@thunk.org>
On Wed, Apr 03, 2013 at 08:33:17AM -0400, Theodore Ts'o wrote:
> On Wed, Apr 03, 2013 at 02:58:31PM +0400, Dmitry Monakhov wrote:
> > All new features are broken on bigendian hosts due to lack of conversion:
> > es_cache: https://lkml.org/lkml/2013/3/28/64
> > inode's csum and ext_to_ind_migrate are also broken.
> >
> > Testcase: make C=2 CF="-D__CHECK_ENDIAN__
> >
> > Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
>
> Thanks for this comprehensive patch. I'm currently trying to decide
> how much of this I should try to push in before the next 3.9-rcX
> window, and how much can wait until the next merge window.
>
> We definitely want to fix the fs corruption bug for big-endian
> systems. For the rest, I'm on the fence, since they are less likely
> to bite people hard --- metadata checksum is still pretty new and not
> fully supported, and the punch hole bug is again also pretty new
> functionality.
>
> Also, pushing something to Linus now could potentially disrupt the
> patches in the ext4 dev tree for the next merge window. For the zero
> extents problem, there's no question what are priorities should be;
> user dataloss trumps developer convenience any day. For the rest,
> what do you all think? Are they likely to hit people hard enough that
> it's worth trying to get this to Linus sooner, as opposed to having
> the fixes for the rest of the big endian issues land in 3.10 and
> 3.9.1?
Hi Ted,
I agree with you that we need to fix the big-endian bug in extent tree
because it affects all people who use ext4 file system. Meanwhile I
think we need to fix the problem in punching hole and xattr because that
has been there. I have looked at Dmitry's patch, and it fixes some
problems that is only in dev branch (e.g. migration). I think this
problem can be fixed in 3.10 later. Meanwhile metadata_csum is still
under ext4dev. So I think it also can be fixed in next merge window.
Thanks,
- Zheng
next prev parent reply other threads:[~2013-04-03 12:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-03 10:58 [PATCH 1/2] ext4: fix usless declarations Dmitry Monakhov
2013-04-03 10:58 ` [PATCH 2/2] ext4: fix cpu_vs_disk conversions Dmitry Monakhov
2013-04-03 12:33 ` Theodore Ts'o
2013-04-03 12:58 ` Dmitry Monakhov
2013-04-03 13:04 ` Zheng Liu [this message]
2013-04-03 16:01 ` Theodore Ts'o
2013-04-03 15:37 ` Theodore Ts'o
2013-04-03 15:55 ` Dmitry Monakhov
2013-04-04 14:42 ` Dmitry Monakhov
2013-04-10 4:01 ` Theodore Ts'o
2013-04-10 4:02 ` [PATCH 1/3] ext4: fix big-endian bug in extent migration code Theodore Ts'o
2013-04-10 4:02 ` [PATCH 2/3] ext4: fix big-endian bug in metadata checksum calculations Theodore Ts'o
2013-04-10 4:02 ` [PATCH 3/3] ext4: fix miscellaneous big endian warnings Theodore Ts'o
2013-04-03 12:26 ` [PATCH 1/2] ext4: fix usless declarations Theodore Ts'o
2013-04-03 12:31 ` Dmitry Monakhov
2013-04-10 2:50 ` [1/2] " Theodore Ts'o
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=20130403130443.GA16014@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=dmonakhov@openvz.org \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=wenqing.lz@taobao.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.