All of lore.kernel.org
 help / color / mirror / Atom feed
From: jim owens <jowens@hp.com>
To: Goffredo Baroncelli <kreijack@alice.it>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Mass-Hardlinking Oops
Date: Mon, 12 Oct 2009 14:07:22 -0400	[thread overview]
Message-ID: <4AD3705A.5000000@hp.com> (raw)
In-Reply-To: <200910121909.56545.kreijack@alice.it>

Goffredo Baroncelli wrote:
> I don't know a software which need so many hard links. But it easy to find 
> some similar cases.
> 
> For example under my "/usr/bin" I have 478 _"soft links"_ to _different_ 
> files.

Hard link is not used in place of soft link... soft link is
a different and preferred addition to posix style systems.

So don't think we need more hard links just because you find
apps using soft links.

> When a directory is created, its ".." entry is a hard link to the "parent" 
> directory. For example the /usr/share/doc directory has 2828 "hard links" 
> because it has 2826 children directories.

Max subdirectories per directory is again a different feature.

btrfs does not use "hard link count" for subdirectories.

That association of "hard links-2" == "max subdirs" is only a legacy
of the design of some filesystems such as UFS.

> These cases are different cases. But the 311 "hard link to the same file under 
> the same directory" limit may be too strong. Not now but in the next format 
> change I think that it would be useful to remove this limit.

I would agree if the cost was 0, but it increases a field size so
it would be nice to have a justified need.  But it is Chris's call.

jim

  reply	other threads:[~2009-10-12 18:07 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-01 13:16 Mass-Hardlinking Oops Raskin Michael
2009-08-03 14:57 ` Chris Mason
2009-08-03 15:00   ` Tomasz Chmielewski
2009-08-03 20:01     ` Mikhail Raskin
2009-10-11 15:05       ` Pär Andersson
2009-10-11 22:43         ` Yan, Zheng 
2009-10-12  8:07           ` Tomasz Chmielewski
2009-10-12 12:47             ` Chris Mason
2009-10-13  7:07               ` Florian Weimer
2009-10-13  7:28                 ` Yan, Zheng 
2009-10-14  0:29               ` Matteo Frigo
2009-10-15 17:55                 ` Tracy Reed
2009-10-15 18:27                   ` Tomasz Chmielewski
2009-10-15 19:15                   ` Oystein Viggen
2009-10-16 22:17                 ` Pär Andersson
2009-10-12 16:16         ` jim owens
2009-10-12 17:09           ` Goffredo Baroncelli
2009-10-12 18:07             ` jim owens [this message]
2009-10-12 17:42           ` John Dong
2009-10-12 18:17             ` jim owens
2009-10-12 20:04               ` Chris Mason
2009-10-12 21:51                 ` berk walker
2009-10-13  0:31                 ` Claudio Martins
2009-10-13  3:42               ` Anthony Roberts
2009-10-13  9:08             ` Brian Brunswick
2009-10-13 17:45             ` Zach Brown
2009-10-13 20:03               ` Chris Mason
2009-10-13 20:55                 ` Zach Brown
2009-10-12 20:50           ` Tomasz Chmielewski

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=4AD3705A.5000000@hp.com \
    --to=jowens@hp.com \
    --cc=kreijack@alice.it \
    --cc=linux-btrfs@vger.kernel.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 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.