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
prev parent 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