linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	tytso@mit.edu, adilger@sun.com, jack@suse.cz,
	david@fromorbit.com, xemul@openvz.org
Subject: Re: Ping.
Date: Sat, 15 May 2010 10:34:41 +0100	[thread overview]
Message-ID: <20100515093441.GA20809@ZenIV.linux.org.uk> (raw)
In-Reply-To: <87y6gp2brh.fsf@openvz.org>

On Thu, Apr 15, 2010 at 03:30:58PM +0400, Dmitry Monakhov wrote:

> > As long as you still have the awkward ifdefs and different semantics for
> About ifdefs style:
> How can i avoid CONFIG_PROJECT_ID without bloating inode size?
> embedded people will kill me for this.
> I just act similar quota code, or you want protect prjid logic 
> via quota config option?
> I don't remember, are we already talk about this?
> If so please remind me your vision.

You have way more ifdefs than just that.

E.g. struct iattr ones are pure junk; it's not kept around for long
time.  Moreover, since ATTR_... is not userland-reachable, you can
bloody well #define ATTR_PRJID to 0 and get rid of more ifdefs.
Ifdefs due to accesses to i_prjid can be reduced to just two inlined
helpers (get_prjid/set_prjid) and there you go...

As for the ->i_prjid itself, I'd buy ifdef there, but _not_ in that
place within structure.  You are shoving it between two pointers;
think of alignment.

As for the isolation...  Why do we care about link/rename at all?
All stuff with the same project ID gets counted together, wherever
in the tree it might be.  It's not as if we'd been scanning a subtree
and calculate the sum over it, after all.  So what is the problem?
Some bastard DoSing you by creating links from places you can't write
to?  Then you want as much isolation as possible anyway, TYVM, and
bind-as-link-barrier is entirely appropriate there.

> > "isolation" vs "not"  there's still a NACK from me.  But in the end Al
> > will have to decide if he wants to take your patches or not.

I want details on use cases and semantics for isolation stuff; as it is,
it looks rather odd.  Why move towards "neutral" part of the tree is
allowed and links over there are not, for example?

  reply	other threads:[~2010-05-15  9:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-18 14:02 [PATCH 0/5] RFC: introduce extended inode owner identifier v6 Dmitry Monakhov
2010-03-18 14:02 ` [PATCH 1/5] vfs: Add additional owner identifier Dmitry Monakhov
2010-03-18 14:02   ` [PATCH 2/5] quota: Implement project id support for generic quota Dmitry Monakhov
2010-03-18 14:02     ` [PATCH 3/5] ext4: Implement project ID support for ext4 filesystem Dmitry Monakhov
2010-03-18 14:02       ` [PATCH 4/5] ext4: add project quota support Dmitry Monakhov
2010-03-18 14:02         ` [PATCH 5/5] ext4: add isolated project support Dmitry Monakhov
2010-03-18 21:25       ` [PATCH 3/5] ext4: Implement project ID support for ext4 filesystem Andreas Dilger
2010-03-19  8:16         ` Dmitry Monakhov
2010-04-06  9:00 ` Ping Dmitry Monakhov
2010-04-13 18:14   ` Ping Christoph Hellwig
2010-04-15 11:30     ` Ping Dmitry Monakhov
2010-05-15  9:34       ` Al Viro [this message]
2010-04-30 12:14     ` Ping to Al Pavel Emelyanov

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=20100515093441.GA20809@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=adilger@sun.com \
    --cc=david@fromorbit.com \
    --cc=dmonakhov@openvz.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=xemul@openvz.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 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).