[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87tyd31fkc.fsf@devron.myhome.or.jp>
Date: Tue, 10 May 2011 10:59:15 +0900
From: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To: "Darrick J. Wong" <djwong@...ibm.com>
Cc: Theodore Tso <tytso@....edu>, Jan Kara <jack@...e.cz>,
Alexander Viro <viro@...iv.linux.org.uk>,
Jens Axboe <axboe@...nel.dk>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Jeff Layton <jlayton@...hat.com>,
Dave Chinner <david@...morbit.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Dave Hansen <dave@...ux.vnet.ibm.com>,
Christoph Hellwig <hch@...radead.org>, linux-mm@...ck.org,
Chris Mason <chris.mason@...cle.com>,
Joel Becker <jlbec@...lplan.org>,
linux-scsi <linux-scsi@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-ext4@...r.kernel.org, Mingming Cao <mcao@...ibm.com>
Subject: Re: [PATCHSET v3.1 0/7] data integrity: Stabilize pages during writeback for various fses
"Darrick J. Wong" <djwong@...ibm.com> writes:
> To assess the performance impact of stable page writes, I moved to a disk that
> doesn't have DIF support so that I could measure just the impact of waiting for
> writeback. I first ran wac with 64 threads madly scribbling on a 64k file and
> saw about a 12 percent performance decrease. I then reran the wac program with
> 64 threads and a 64MB file and saw about the same performance numbers. As I
> suspected, the patchset only seems to impact workloads that rewrite the same
> memory page frequently.
>
> I am still chasing down what exactly is broken in ext3. data=writeback mode
> passes with no failures. data=ordered, however, does not pass; my current
> suspicion is that jbd is calling submit_bh on data buffers but doesn't call
> page_mkclean to kick the userspace programs off the page before writing it.
>
> Per various comments regarding v3 of this patchset, I've integrated his
> suggestions, reworked the patch descriptions to make it clearer which ones
> touch all the filesystems and which ones are to fix remaining holes in specific
> filesystems, and expanded the scope of filesystems that got fixed.
>
> As always, questions and comments are welcome; and thank you to all the
> previous reviewers of this patchset. I am also soliciting people's opinions on
> whether or not these patches could go upstream for .40.
I'd like to know those patches are on what state. Waiting in writeback
page makes slower, like you mentioned it (I guess it would more
noticeable if device was slower that like FAT uses). And I think
currently it doesn't help anything others for blk-integrity stuff
(without other technic, it doesn't help FS consistency)?
So, why is this locking stuff enabled always? I think it would be better
to enable only if blk-integrity stuff was enabled.
If it was more sophisticate but more complex stuff (e.g. use
copy-on-write technic for it), I would agree always enable though.
Thanks.
--
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists