svn commit: r269523 - head/sys/fs/ext2fs
Pedro Giffuni
pfg at freebsd.org
Mon Aug 4 22:36:41 UTC 2014
Il giorno 04/ago/2014, alle ore 14:01, Bruce Evans <brde at optusnet.com.au> ha scritto:
> On Mon, 4 Aug 2014, Pedro F. Giffuni wrote:
>
>> Log:
>> set EXT2_LINK_MAX to LINK_MAX
>>
>> 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.
>
> 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.
>
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.
>>
>> MFC after: 3 days
>>
>> Modified:
>> head/sys/fs/ext2fs/ext2_dir.h
>>
>> Modified: head/sys/fs/ext2fs/ext2_dir.h
>> ==============================================================================
>> --- 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
>>
>> /*
>> * Ext2 directory file types. Only the low 3 bits are used. The
>
> 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?).
>
> 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.
>
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’ve also let us reuse NetBSD’s
(possibly broken) ext2.
The cleanest solution is probably to make the limit dynamical.
I will revert this change and see if it’s 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.
>
> Bruce
More information about the svn-src-head
mailing list