linux-ext4 - Re: [PATCH 1/2] [PATCH] ext4: Add inode to the orphan list during block allocation failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090605234238.GF11650@duck.suse.cz>
Date:	Sat, 6 Jun 2009 01:42:39 +0200
From:	Jan Kara <jack@...e.cz>
To:	Theodore Tso <tytso@....edu>
Cc:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/2] [PATCH] ext4: Add inode to the orphan list during
	block allocation failure

On Fri 05-06-09 03:24:17, Theodore Tso wrote:
> On Fri, Jun 05, 2009 at 02:22:34AM -0400, Theodore Tso wrote:
> > I've tried applying these two patches to the ext4 patch queue.  On a
> > metadata-heavy workload (specifically, fsx), it causes a 5%
> > degradation in the wall clock run-time of the fsx run-time.
> 
> I just did some more timing tests, and it looks like I can't confirm
> it.  The test times are noisy enough I need to run some more under very
> controlled circumsntances.  So ignore this for now, it might not be a
> problem after all.
  It would be strange if the patches caused a measurable slowdown. They
change something only in the failure path where we fail to allocate some
blocks or fail to copy in all the data and these should better be
exceptional cases...

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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