linux-ext4 - Re: [PATCH v2 0/4] quota: add project quota support

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: <20140811144112.GC3506@thunk.org>
Date:	Mon, 11 Aug 2014 10:41:12 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Li Xi <pkuelelixi@...il.com>
Cc:	linux-fsdevel@...r.kernel.org,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	viro@...IV.linux.org.uk, hch@...radead.org, Jan Kara <jack@...e.cz>
Subject: Re: [PATCH v2 0/4] quota: add project quota support

On Sat, Aug 09, 2014 at 12:39:58AM +0800, Li Xi wrote:
> It is obvious that extended attribute implementation has performance
> impact when creating files. That is why we choose to push the patches
> which use internal inode field to save project ID.

Looking at your numbers more closely, I bit you are parsing the
extended attributes each time you need to adjust the project quota for
the file, correct?  I suspect that if you cache the project ID in the
in-memory struct ext4_inode_info, the performance difference between
using an extended attribute versus an internal inode field will be
negligible.  The only difference would be a tiny amount of CPU time
when you first create the inode, and when you read the inode from the
inode table block on disk, since the project ID will under normal
circumstances never or hardly ever change.

Regards,

					- 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