All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Fasheh <mfasheh@suse.de>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [patch 09/15] ocfs2: add functions to add and remove inode in	orphan dir
Date: Fri, 19 Dec 2014 12:33:52 -0800	[thread overview]
Message-ID: <20141219203352.GY7238@wotan.suse.de> (raw)
In-Reply-To: <54939D94.7040308@huawei.com>

On Fri, Dec 19, 2014 at 11:37:56AM +0800, Joseph Qi wrote:
> Hi Mark,
> I much appreciate your pertinent comments on this feature.
> 
> The reason we use orphan dir is to make sure allocating blocks and
> updating inode size consistent, and this will result an entry in orphan
> is not truly deleted one.

Right, I got that from the patch. Good idea by the way.


> To distinguish dio from unlink, we introduce a new dinode flag
> OCFS2_DIO_ORPHANED_FL.

Ok, that's also good.


> So after this change, once unlink and dio happen concurrently, there
> may be two kinds of results:
> 1. On the same node, only one entry will be added with flag
> OCFS2_ORPHANED_FL, and flag OCFS2_DIO_ORPHANED_FL will be set and clear
> during dio.
> 2. On different nodes, two entries will be added with each flag
> OCFS2_ORPHANED_FL or OCFS2_DIO_ORPHANED_FL.
> 
> Since entry name is stringified from blkno and the length is fixed
> OCFS2_ORPHAN_NAMELEN, so adding a prefix as you suggested may affect
> too much.

No, adding the prefix is much more preferable to intentionally corrupting
the conents of a directory. That OCFS2_ORPHAN_NAMELEN is a #define does not
matter, you are free to make it whatever reasonable value fits the name. The
directory code naturally handles this, whtether the length is
OCFS2_ORPHAN_NAMELEN or OCFS2_ORPHAN_NAMELEN + PREFIX_NAMELEN.

Also if you were to run fsck against the file system it will (should) complain
about having duplciate entries in the orphan dir.

Aside from the corruption issue, there are usability issues too. Someone
running "ls //orphan_dir:0000" will not be able to tell whether a name is
there for dio or nlink==0. If you prefix it, then debugging becomes much
easier.


Btw, did you see my note about a readonly superblock flag for this? We're
going to need to handle backward compatibility too.
	--Mark

--
Mark Fasheh

  reply	other threads:[~2014-12-19 20:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-15 22:51 [Ocfs2-devel] [patch 09/15] ocfs2: add functions to add and remove inode in orphan dir akpm at linux-foundation.org
2014-12-18 23:18 ` Mark Fasheh
2014-12-19  3:37   ` Joseph Qi
2014-12-19 20:33     ` Mark Fasheh [this message]
2014-12-22  1:04       ` Joseph Qi
2014-12-22  7:06         ` Mark Fasheh
2015-01-13  8:36           ` Joseph Qi
2015-01-16 22:56             ` Mark Fasheh

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=20141219203352.GY7238@wotan.suse.de \
    --to=mfasheh@suse.de \
    --cc=ocfs2-devel@oss.oracle.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 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.