From: Mingming Cao <cmm@us.ibm.com>
To: Andreas Dilger <adilger@sun.com>
Cc: Kalpak Shah <Kalpak.Shah@sun.com>,
linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] Large EAs in ext4
Date: Mon, 25 Aug 2008 17:12:25 -0700 [thread overview]
Message-ID: <1219709545.6394.45.camel@mingming-laptop> (raw)
In-Reply-To: <20080825224736.GZ3392@webber.adilger.int>
在 2008-08-25一的 16:47 -0600,Andreas Dilger写道:
> On Aug 25, 2008 21:30 +0530, Kalpak Shah wrote:
> > This is the implementation for large EA support in ext4. Note that this
> > also helps to have a larger number of EAs since large EAs get written
> > out to a new inode instead of the EA block.
> >
> > If value of an attribute is greater than 2048 bytes the value is not
> > saved in the external EA block, instead it is saved in an inode.
>
> I just realized that this needs to be (blocksize / 2) instead of 2048,
> or we will never get the EA inodes in case of 1kB/2kB block filesystem
> where we need it the most.
>
> > +struct inode *ext4_xattr_inode_iget(struct inode *parent, int ea_ino, int *err)
> ^^ extra space here
>
> > + if (ea_inode->i_mtime.tv_sec != parent->i_ino ||
>
> Do you think it makes sense to "#define i_xattr_inode_parent i_mtime.tv_sec"
> in case there is a decision to change which field is used? Or do people
> think that is more confusing than helpful?
>
> Note to readers that this is a new patch, and Lustre doesn't use it yet,
> but we'd like to in the relatively near future so feedback that affects
> the on disk format is preferred sooner than later.
>
> > +ext4_xattr_inode_set(handle_t *handle, struct inode *inode, int *ea_ino,
> > + const void *value, size_t value_len)
> > +{
> > + /*
> > + * Make sure that enough buffer credits are available else extend the
> > + * transaction.
> > + */
> > + req_buffer_credits = (value_len / inode->i_sb->s_blocksize) + 4;
>
> Can you please explain in the comment what the "+ 4" blocks are?
> I suspect this will not be enough if the xattr is large, it should just
> use one of the standard "transaction size" helper functions to determine
> metadata size.
>
ext4_meta_trans_blocks() will gives the metadata size, which also
account for block group bitmap and block group descriptor blocks,
superblock, inode block.
also here
> @@ -1059,10 +1352,23 @@ ext4_xattr_set(struct inode *inode, int
> const void *value, size_t value_len, int flags)
> {
> handle_t *handle;
> + int buffer_credits;
> int error, retries = 0;
> + buffer_credits = EXT4_DATA_TRANS_BLOCKS(inode->i_sb);
> + if ((value_len >= EXT4_XATTR_MIN_LARGE_EA_SIZE) &&
> + (EXT4_SB(inode->i_sb)->s_es->s_feature_incompat &
> + EXT4_FEATURE_INCOMPAT_EA_INODE)) {
> + /* For new inode */
> + buffer_credits += > > >EXT4_SINGLEDATA_TRANS_BLOCKS(inode->i_sb) +3;
> +
> + /* For the blocks to be written in the EA inode */
> + buffer_credits += (value_len + inode->i_sb->s_blocksize - 1) /
> + inode->i_sb->s_blocksize;
> + }
> +
> retry:
> - handle = ext4_journal_start(inode, > EXT4_DATA_TRANS_BLOCKS(inode->i_sb));
> + handle = ext4_journal_start(inode, buffer_credits);
> if (IS_ERR(handle)) {
> error = PTR_ERR(handle);
> } else {
the credits calculation could be replaced with something like this:
nrblocks = (value_len + inode->i_sb->s_blocksize - 1) / inode->i_sb->s_blocksize;
buffer_credits = ext4_meta_trans_blocks(inode, nrblocks, 1) + nrblocks;
BTW, I think we should update the xttars credits micro in ext4_jbd2.h,
that is based on 1 xattr block assumption...
/* Extended attribute operations touch at most two data buffers,
* two bitmap buffers, and two group summaries, in addition to the inode
* and the superblock, which are already accounted for. */
#define EXT4_XATTR_TRANS_BLOCKS 6U
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2008-08-26 0:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-25 16:00 [PATCH] Large EAs in ext4 Kalpak Shah
2008-08-25 22:47 ` Andreas Dilger
2008-08-26 0:12 ` Mingming Cao [this message]
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=1219709545.6394.45.camel@mingming-laptop \
--to=cmm@us.ibm.com \
--cc=Kalpak.Shah@sun.com \
--cc=adilger@sun.com \
--cc=linux-ext4@vger.kernel.org \
/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.