Date: Mon, 4 Aug 2014 17:36:30 -0500 From: Pedro Giffuni <pfg@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r269523 - head/sys/fs/ext2fs Message-ID: <4637A4B5-F27E-488B-90E8-31B9A5DF2AAD@freebsd.org> In-Reply-To: <20140805041657.A1066@besplex.bde.org> References: <53dfb7a3.5e19.37746e44@svn.freebsd.org> <20140805041657.A1066@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Il giorno 04/ago/2014, alle ore 14:01, Bruce Evans =
<brde@optusnet.com.au> ha scritto:
> On Mon, 4 Aug 2014, Pedro F. Giffuni wrote:
>=20
>> Log:
>> set EXT2_LINK_MAX to LINK_MAX
>>=20
>> In linux EXT4_LINK_MAX is now 64000. We can't really do that
>> since i_nlink and va_nlink are signed so setting higher values
>> is likely to cause trouble.
>=20
> Hmm, va_nlink doesn't use nlink_t and is inconsistent with nlink_t
> since nlink_t is unsigned. The bug is nlink_t being unsigned.
> Signed for i_nlink is more reasonable although it is inconsistent
> with unsigned for e2di_nlink. The implementation might want to
> use the better arithmetic of signed types. However, it blindly
> converts from unsigned to signed when converting e2di_nlink to
> i_nlink, so it overflows for corrupt file systems with e2di_nlink
> larger than 32767.
>=20
While I agree in general, the correct type for e2di_nlink, is defined by =
the linux implementation.
It is very possible to find correct ext4 filesystems where e2di_nlink is =
50000. In fact the OpenBSD
guys are claiming they can access such filesystems.
>> This is a system limitation so set the EXT_LINK_MAX to
>> what the system can handle.
>>=20
>> MFC after: 3 days
>>=20
>> Modified:
>> head/sys/fs/ext2fs/ext2_dir.h
>>=20
>> Modified: head/sys/fs/ext2fs/ext2_dir.h
>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>> --- head/sys/fs/ext2fs/ext2_dir.h Mon Aug 4 16:32:08 2014 =
(r269522)
>> +++ head/sys/fs/ext2fs/ext2_dir.h Mon Aug 4 16:41:06 2014 =
(r269523)
>> @@ -72,7 +72,7 @@ struct ext2fs_direct_2 {
>> /*
>> * Maximal count of links to a file
>> */
>> -#define EXT2_LINK_MAX 32000
>> +#define EXT2_LINK_MAX LINK_MAX
>>=20
>> /*
>> * Ext2 directory file types. Only the low 3 bits are used. The
>=20
> This breaks ext2 where the limit is 32000. It allows creating corrupt
> file systems containing inodes with more than 32000 links. The
> corruption would be noticed by ext2fs implemenations with a non-broken
> limit and should be noticed by ext2fsck. The failure modes in the
> previous version of ext2fs in FreeBSD seem to be limited to operations
> that increase the link count further (including temporary increases =
for
> rename?).
>=20
> Old versions of ext2fs in FreeBSD had the same bug in a worse way. =
They
> defined EXT2_LINK_MAX as 32000 but never used it. They used the =
system
> LINK_MAX instead.
>=20
FWIW, NetBSD reuses the UFS value and I pretended to do the same.
Reusing this value, gives us 767 more directories in ext4, which is not
a huge difference but perhaps useful. It would=92ve also let us reuse =
NetBSD=92s
(possibly broken) ext2.
The cleanest solution is probably to make the limit dynamical.
I will revert this change and see if it=92s worth it. (probably not for =
just
767 directories ?).
Regards,
Pedro.
> Old versions of linux (2.6.10) have many bugs related to LINK_MAX, but
> not this one. {LINK_MAX} is variable. Thus LINK_MAX must not be
> defined in <limits.h>. But it is defined in <limits.h>, with a value
> of 127 that is too small for most file systems. Many nearby variable
> limits that must not be defined are defined (the worst one in practice
> is {OPEN_MAX}. Similarly in FreeBSD, except the LINK_MAX that must
> not be defined in <limits.h> is defined as large enough for all file
> systems. Back in linux, nlink_t is uint16_t on some arches including
> x86, but JFS_LINK_MAX is 0xffffffff. I can't see where pathconf()
> returns an fs-dependent (or file-dependent) limit.
>=20
> Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4637A4B5-F27E-488B-90E8-31B9A5DF2AAD>