mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jan Harkes <jaharkes@cs.cmu.edu>
To: Uli Martens <um@scientific.de>
Cc: Christoph Rohland <cr@sap.com>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch] tmpfs: incr. link-count on directory rename
Date: Thu, 14 Feb 2002 01:19:33 -0500	[thread overview]
Message-ID: <20020214061933.GA17774@mentor.odyssey.cs.cmu.edu> (raw)
In-Reply-To: <1013648840.2317.5.camel@isax>
In-Reply-To: <1013648840.2317.5.camel@isax>

On Thu, Feb 14, 2002 at 02:07:18AM +0100, Uli Martens wrote:
> When I move a directory into another on a tmpfs filesystem, the
> link-count of the new parent directory isn't getting incremented. 
> (which leads to find getting hickup, which eg. lets dpkg produce a
> "bzip2" binary package without binaries, generally not a nice thing) 

Yeah, that optimization actually breaks on so many filesystems
(AFS/Coda/iso9660/msdos/any filesystem which contains more than 65538
subdirectories in a directory/you name it) that they even provided a
flag to disable it (-noleaf), which in my opinion should always be the
default setting.

Another trick on the 'filesystem side' of things is to set the directory
linkcount to 1. Basically find always subtracts 2 and then as long as
the count is not zero, it will stat the entry to see if it's a
directory. So a directory linkcount of 1 will 'underflow' and find will
work correctly for the first 65535 sub-directories.

It's been on my todo list to use this fix in Coda as we have some link
count issues when we're flipping entries between 'faked' symlinks for
mountpoints/conflicts and real directories.

Jan

> @@ -1085,6 +1085,9 @@
>  {
>         int error = -ENOTEMPTY;
>  
> +       if (S_ISDIR(old_dentry->d_inode->i_mode)) {
> +               new_dir->i_nlink++;
> +       }
>         if (shmem_empty(new_dentry)) {
>                 struct inode *inode = new_dentry->d_inode;
>                 if (inode) {

ps. shouldn't the linkcount of the old_dir get decremented too? Also you
should only change the linkcounts when the operation completed
successfully. i.e. something more like,

--- /tmp/shmem.c.orig	Thu Feb 14 01:17:23 2002
+++ /tmp/shmem.c	Thu Feb 14 01:18:25 2002
@@ -1100,6 +1100,10 @@
 		error = 0;
 		old_dentry->d_inode->i_ctime = old_dir->i_ctime = old_dir->i_mtime = CURRENT_TIME;
 	}
+	if (!error && S_ISDIR(old_dentry->d_inode->i_mode)) {
+	    old_dir->i_nlink--;
+	    new_dir->i_nlink++;
+	}
 	return error;
 }
 

  reply	other threads:[~2002-02-14  6:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-14  1:07 Uli Martens
2002-02-14  6:19 ` Jan Harkes [this message]
2002-02-14  9:34 ` Uli Martens
2002-02-19 16:39   ` Christoph Rohland

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=20020214061933.GA17774@mentor.odyssey.cs.cmu.edu \
    --to=jaharkes@cs.cmu.edu \
    --cc=cr@sap.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=um@scientific.de \
    /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

all inboxes | Powered by JetHome®