All of lore.kernel.org
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@kernel.org>
To: Andy Smith <andy@strugglers.net>
Cc: Lukas Straub <lukasstraub2@web.de>, linux-btrfs@vger.kernel.org
Subject: Re: "Too many links (31)" issue
Date: Fri, 4 Feb 2022 14:30:17 +0000	[thread overview]
Message-ID: <Yf04eXr3KqG4BYZP@debian9.Home> (raw)
In-Reply-To: <20220203222752.7x4nq4y6wgi6anfi@bitfolk.com>

On Thu, Feb 03, 2022 at 10:27:52PM +0000, Andy Smith wrote:
> Hi Lukas,
> 
> On Thu, Feb 03, 2022 at 10:15:06PM +0000, Lukas Straub wrote:
> > On Thu, 3 Feb 2022 16:31:08 +0000
> > Andy Smith <andy@strugglers.net> wrote:
> > > I searched around on this topic and found hits from 10 years ago
> > > about maximum hardlinks per directory and being dependent upon
> > > length of file path. Is that still relevant today?
> > > 
> > > [...]
> > > 
> > > Is there anything I can do to get this working?
> > 
> > Hello, Have you tried the "extended_iref" mount option? 
> 
> During my searching I did see mention of it, but as far as I could
> see this is a mkfs feature not a mount option, and it's default on
> now anyway. So I already have it don't I? (how to check enabled
> filesystem features?)

Yes, it's a feature enabled by mkfs, and it has been enabled by
default for many years now.

You can confirm if it's enabled like this:

$ cat /sys/fs/btrfs/80353f52-8425-45c2-a9a2-103c3e25ebb9/features/extended_iref 
1

Where the 8035(...) is the UUID of the mounted filesystem.
You can get the UUID using blkid:

$ blkid
(...)
/dev/sdj: UUID="80353f52-8425-45c2-a9a2-103c3e25ebb9" UUID_SUB="0d1e7dfe-6ec8-494c-8467-bc4eabca56f2" BLOCK_SIZE="4096" TYPE="btrfs"
(...)

With extent irefs, the hard link limit is 65535 (64K - 1), I just confirmed
with a quick test that it is indeed being respected:

$ mkfs.btrfs -f /dev/sdj
$ mount /dev/sdj /mnt/sdj
$ cd /mnt/sdj
$ touch foo
$ for ((i = 1; i < 65536; i++)); do echo "Iteration $i"; ln foo foo_$i; done
(...)
Iteration 65534
Iteration 65535
ln: failed to create hard link to 'foo': Too many links

$ stat foo
  File: foo
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 2ch/44d	Inode: 257         Links: 65535
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-02-04 14:18:49.788113075 +0000
Modify: 2022-02-04 14:18:49.788113075 +0000
Change: 2022-02-04 14:21:58.432166650 +0000
 Birth: 2022-02-04 14:18:49.788113075 +0000

$ ls -1 | wc -l
65535


> 
> Anyway, it is not recognised as a mount option.
> 
> Cheers,
> Andy

      reply	other threads:[~2022-02-04 14:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-03 16:31 "Too many links (31)" issue Andy Smith
2022-02-03 22:15 ` Lukas Straub
2022-02-03 22:27   ` Andy Smith
2022-02-04 14:30     ` Filipe Manana [this message]

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=Yf04eXr3KqG4BYZP@debian9.Home \
    --to=fdmanana@kernel.org \
    --cc=andy@strugglers.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lukasstraub2@web.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 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.