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