All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikita Danilov <Nikita@Namesys.COM>
To: David Masover <jedi@ninja.dynup.net>
Cc: reiserfs-list@namesys.com
Subject: Re: More on Hard Links (was A bold idea (Re: Carrying Attributes too Far))
Date: Fri, 5 Dec 2003 17:17:48 +0300	[thread overview]
Message-ID: <16336.37772.88198.217245@laputa.namesys.com> (raw)
In-Reply-To: <3FD0912C.1090700@ninja.dynup.net>

David Masover writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > Alexander G. M. Smith wrote:
 > 
 > >David Masover wrote on Thu, 04 Dec 2003 21:58:42 -0600:
 > >  
 > >
 > >>I agree that hardlinking directories should be allowed, and I think it's
 > >>worth it to check whether it creates a loop, unless rm can be modified
 > >>to simply rm the directory, and the filesystem (and maybe VFS) would be
 > >>modified to have directories have link counts that don't include . or
 > >>.., so when a directory is to be deleted, the system does its own manual
 > >>deletion of each of the files within it.  Then, if I type 'rm loop' and
 > >>it removes the link of 'loop/loop' to 'loop', there are now no more
 > >>links to 'loop' and it gets destroyed.
 > >>    
 > >>
 > >
 > >I think you need more than link counts.  Like I mentioned earlier, I used
 > >a graph traversal in my BeOS file system to handle deletion of loops.
 > >
 > >Unfortunately that implies locking potentially large numbers of files while
 > >doing the traversal, which can fail or deadlock if the file system is in
 > >continuous use (like it might be on a server).  But then you already have
 > >that sort of problem on regular file systems, though only for one file at
 > >a time.
 > >  
 > >
 > Yes, locking, as a transaction.  Which means either the whole deletion 
 > fails (couldn't get the lock, user got annoyed and hit ^C) or it 
 > succeeds (got lock on all the files by doing some sort of recursive lock 
 > on the root dir).  From inside the transaction, it should look as though 
 > everything is happening in realtime, but it only flushes when it can get 
 > the lock.  (right?)

Deadlock detection and/or avoidance will be a nightmare to
implement. And at one point or another you need to keep all directories
in the "closure" to be locked, which means, that their inodes have to be
in memory, which means that if file-size / mem-size ratio is large, you
are in trouble.

Look at this from another point of view: deletion of a file when its
last name is removed is but a form of the garbage
collection. Traditionally UNIX implemented reference counted garbage
collectors for this, which was fine, because UNIX file system is a tree
(modulo dots and dotdots). But if multiple hard-links to the directories
are allowed, file system is an arbitrary graph. It makes little sense to
try to stretch reference counting to work in this situation. There are
much more efficient forms of garbage collection for this.

Nikita.

  reply	other threads:[~2003-12-05 14:17 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-04  5:58 Carrying Attributes too Far lrc1
2003-10-04 18:17 ` Alexander G. M. Smith
2003-10-04 20:10 ` Hubert Chan
2003-12-03 19:18 ` Hans Reiser
2003-12-05  0:30   ` lrc1
2003-12-05  3:58     ` A bold idea (Re: Carrying Attributes too Far) David Masover
2003-12-05  9:44       ` Heinz-Josef Claes
2003-12-05 14:00         ` David Masover
2003-12-05 16:37           ` Hubert Chan
2003-12-06  1:38             ` David Masover
2003-12-06  4:01               ` Hubert Chan
2003-12-06 17:40                 ` David Masover
2003-12-06 22:41             ` lrc1
2003-12-07  1:18               ` carrying links too far? (was Re: A bold idea (Re: Carrying Attributes too Far)) David Masover
2003-12-07  2:26                 ` Hubert Chan
2003-12-07  9:08                   ` The danger of bad external links lrc1
2003-12-07 18:15                     ` Hubert Chan
2003-12-07 13:18                 ` carrying links too far? (was Re: A bold idea (Re: Carrying Attributes too Far)) lrc1
2003-12-07 16:17                   ` David Masover
2003-12-07 18:25                   ` Hubert Chan
2003-12-07  2:11               ` A bold idea (Re: Carrying Attributes too Far) Hubert Chan
2003-12-08 20:54         ` Boyd Waters
2003-12-09  8:03           ` Heinz-Josef Claes
2003-12-10  2:12             ` more about links (was Re: A bold idea (Re: Carrying Attributes too Far)) David Masover
2003-12-11 11:35               ` Heinz-Josef Claes
2003-12-05 13:16       ` More on Hard Links (was " Alexander G. M. Smith
2003-12-05 14:07         ` David Masover
2003-12-05 14:17           ` Nikita Danilov [this message]
2003-12-05 15:58             ` Hans Reiser
2003-12-05 16:18               ` Nikita Danilov
2003-12-06  1:50                 ` Garbage collection for files (was Re: More on Hard Links (was A bold idea (Re: Carrying Attributes too Far))) David Masover
2003-12-07  3:27                   ` Hans Reiser
2003-12-06 10:06                 ` More on Hard Links (was A bold idea (Re: Carrying Attributes too Far)) Stewart Smith
2003-12-05 22:38             ` Alexander G. M. Smith
2003-12-06  1:54               ` David Masover
2003-12-06 15:31                 ` Alexander G. M. Smith
2003-12-07  1:08                   ` David Masover
2003-12-07  2:42                     ` Alexander G. M. Smith
2003-12-09  5:21                       ` More on Hard Links Narcoleptic Electron
2003-12-09 18:48                         ` Hubert Chan
2003-12-09 19:52                           ` Narcoleptic Electron
2003-12-09 21:31                             ` Hubert Chan
2003-12-09 23:47                               ` Narcoleptic Electron
2003-12-10  0:13                                 ` Narcoleptic Electron
2003-12-10  3:05                                   ` Hubert Chan
2004-01-22 21:15                                     ` Narcoleptic Electron
2003-12-10  2:53                                 ` Hubert Chan
2003-12-10  3:22                                 ` Religion and Hard Links (was Re: More on Hard Links) David Masover
2003-12-10 20:49                                 ` More on Hard Links Matt Stegman
2003-12-16  1:27                                 ` Hubert Chan
2003-12-10  2:44                           ` David Masover
2003-12-05  5:27     ` Carrying Attributes too Far Hubert Chan
2003-12-05 12:38     ` Hans Reiser
2003-12-06 23:33       ` lrc1
2003-12-07  2:48         ` Hubert Chan
2003-12-07 17:08         ` Hans Reiser
     [not found]     ` <3FD0023D.5030500@ninja.dynup.net>
2003-12-07  6:37       ` Saved Re: A bold idea (Re: Carrying Attributes too Far) lrc1
2003-12-07  6:39         ` lrc1

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=16336.37772.88198.217245@laputa.namesys.com \
    --to=nikita@namesys.com \
    --cc=jedi@ninja.dynup.net \
    --cc=reiserfs-list@namesys.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.