public inbox for linux-btrfs@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox