linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Shilong Wang <wangshilong1991@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-ext4@vger.kernel.org, Ted Tso <tytso@mit.edu>
Subject: Re: [PATCH 0/4 v2] e2fsprogs: Support for orphan file feature
Date: Wed, 22 Jul 2015 11:18:35 +0200	[thread overview]
Message-ID: <20150722091835.GD17243@quack.suse.cz> (raw)
In-Reply-To: <CAP9B-Qnk1UGSvmaMQdixwNLZRN7L4xW2xWYY6vX877t5uHSr-Q@mail.gmail.com>

  Hi,

On Wed 22-07-15 17:05:28, Shilong Wang wrote:
> 2015-05-26 15:51 GMT+08:00 Jan Kara <jack@suse.cz>:
> 
> >   Hello,
> >
> >   this is the second version of support for orphan file feature in
> > e2fsprogs.
> > Since v1, I have finished and debugged e2fsck support, fixed a couple of
> > issues
> > in mke2fs and tune2fs and also incorporated changes resulting from the
> > review.
> > The only unresolved issue I'm aware of is which reserved inode will we use
> > for
> > this feature.
> >
> > If nobody speaks up, I will pick up patches from Konstantin to support
> > increasing number of reserved inodes (he implemented it in resize2fs, I
> > will
> > move it to tune2fs by moving some resize2fs functionality to libext2fs).
> > That
> > will practically remove the current limitation of the number of reserved
> 
> inodes.
> >
> 
> 
> Any progress about this?  More reserved inodes are also needed  by project
> quota.
> BTW, i noticed if i extend s_first_ino, many e2fsprogs tests will fail
> because
> tests results reiled on previous confirmed system inodes, any idea about
> this?

Yes, I'm working on this on-and-off for some time. I already have separated
functionality to move blocks and to move inodes from resize2fs into
libext2fs. So the hardest part is hopefully done. But it needs testing and
I need to figure out whether some group accounting parts also don't need to
be moved into libext2fs as they may be needed in more places. So overall
it's about one or two days of work to finish this but I get preempted by
other stuff...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

      parent reply	other threads:[~2015-07-22  9:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-26  7:51 [PATCH 0/4 v2] e2fsprogs: Support for orphan file feature Jan Kara
2015-05-26  7:51 ` [PATCH 1/5] libext2fs: " Jan Kara
2015-05-26  7:51 ` [PATCH 2/5] mke2fs: Add support for orphan_file feature Jan Kara
2015-05-26  7:51 ` [PATCH 3/5] e2fsck: Add support for handling orphan file Jan Kara
2015-05-26  7:51 ` [PATCH 4/5] tune2fs: Add support for orphan_file feature Jan Kara
2015-05-26  7:51 ` [PATCH 5/5] mke2fs: Add orphan_file feature into mke2fs.conf Jan Kara
     [not found] ` <CAP9B-Qnk1UGSvmaMQdixwNLZRN7L4xW2xWYY6vX877t5uHSr-Q@mail.gmail.com>
2015-07-22  9:18   ` Jan Kara [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=20150722091835.GD17243@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=wangshilong1991@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).