[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100317005138.GC4874@thunk.org>
Date: Tue, 16 Mar 2010 20:51:38 -0400
From: tytso@....edu
To: Andreas Dilger <adilger@....com>
Cc: "K. V K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 2.6.27.y 04/11] ext4: Add percpu dirty block accounting.
On Tue, Mar 16, 2010 at 12:48:03PM -0600, Andreas Dilger wrote:
>
> Just looking at this old patch, and noticed this is still the same
> in newer versions.
>
> This should probably be either an ext4_error(), since it affects
> data correctness, even though it isn't an on-disk error, or at least
> an ext4_msg() so that it also prints the block device and uses the
> standard ext4 error format.
Yeah, we should convert it to use ext4_msg(); using ext4_error()
doesn't seem appropriate since that will mark the file system as
corrupted, which isn't the case if this isn't an on-disk error. Maybe
a WARN_ON(1) is appropriate so that we get a stack trace and
kerneloops.org tracking?
> In the first patch (ext4-claim-err.diff) the access to the
> superblock for ext4_msg() is a bit of a hack, but I think it isn't
> terrible.
Agreed, this isn't bad.
> The second patch (ext4-error-cleanup.diff, to be used instead of the
> first one) is a bit more thorough cleanup that changes the callers
> to pass a struct super_block, and also removes some single-use stack
> variables in related code.
I haven't looked closely at this one yet, I'm not entirely convinced
the cleanups are worth all of the changes, but I'm willing to be
convinced.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists