From owner-svn-src-all@FreeBSD.ORG Mon Aug 4 22:36:41 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 870A6BAF for ; Mon, 4 Aug 2014 22:36:41 +0000 (UTC) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25D502632 for ; Mon, 4 Aug 2014 22:36:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1407191793; bh=YmrcpPNovCYMLUDdyifEl3Ckj6/bEjF4gkjl4gZPxc8=; h=Received:Received:Received:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=t+Zd6zORaKyVWf3BaUUTvcomJaDODi3VEpnryDuwP/qqW/yNaW8Ym266Ozf9nRwlWn2wItD0n4HtjXwKYNzoZtYw1DkANU0WOazKqop4HGCKggpZDB14um6S2QeE4OQziqwwh1S9j9nQEKZRKIMHys68KoFTWSoHNLveEln8HCJCQhokbDCsrptbML67WxJ303X+Q2ainrkZeUNDLobaByjhF8JYv+nqB0SprCZYR429WS5LQAR+XxhLONwIfNb339eyGD08nX90g4hfn81nDlWV7siQZizqhnohkzMuOegh4qnhS2HsztyMAX8z46CP/n/k47reaood0SxjrCe+oA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=kNRRGV69ygea84x+VBis4fEffNxE+Hf+AL91nmg9AdbWdSNRo+G1v4QuA9Qh2ZhFqg/mwQTnunkQHC+rw04uwD5FbtPQk3OONuzDJ7fZm3OqhPG1tgA6gcPJq5I64Wx9zThEgKLQhijKYXce2yuYOkJiBkwCJ/GdoRKvu/sdkHFLWRo2ozxGoSwp0VfJm4P44NxwzdfsHZTF81GEVXHKVucfy0RptM1l3JWw6zBxc8yekOeUuZWTROD/CBq0E273iRO/mb5KYM/Ui357zoeO0QMqztwOVa9QF57kyua91q4q6zg45TJXw6eKH9WAsnEKvgG0R8vkaXVYzcRJObM4xg==; Received: from [98.139.212.151] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 04 Aug 2014 22:36:33 -0000 Received: from [98.139.211.192] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 04 Aug 2014 22:36:33 -0000 Received: from [127.0.0.1] by smtp201.mail.bf1.yahoo.com with NNFMP; 04 Aug 2014 22:36:33 -0000 X-Yahoo-Newman-Id: 175547.78766.bm@smtp201.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _Wh02mYVM1mwk70VdR9kTV5QY3k6GodGwskUnx8W_A6HTky xnP377DtFuQSS1dmRFxD4fIJt16v6dSpDa7zDPVsTcfm4cc5U4y1JlM6XC7R iFS4Gdy1uRUHy8GMr1EaQgrhNTbSFvboK7gGUgBfb2Lpp5gbaLAPp62DB3xC ivP4CzJd9cCItvnxWgR1UAKpDACk_aGKICPmTQ7DWeR841vCz9QYX6PSTlKw 5QluzLtsNJ3kCtzWghZK.dLXQvaY4vSDSzSjX4UrcRNXuRlU2nAMZVRFM4QP wI6Ctxa5zmL9ivmEt6IlVNLdy55yjo6eCzeIrTlZO1AQv7tbYAAwlUcz0_YE Jis4vw2RSivQlVHnBz8CNArUCegN.3jOOg8E4AVxCBAOoGDmTa901KnNNpgQ SN3oBtGnxLVbFlMv668Us5k1rOVL78i9ub7FzJmf0X3lqSWsG6ZCxNbe5RMy xdO4HFeYWGiz1ry0lxPMsEUCnaNAwjGzQTFxxVS3bYmFBDVgRLR121oVGvvD 4xuR_d7HDnQ5R8bg3oCo_.PBDJ0A- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: svn commit: r269523 - head/sys/fs/ext2fs From: Pedro Giffuni In-Reply-To: <20140805041657.A1066@besplex.bde.org> Date: Mon, 4 Aug 2014 17:36:30 -0500 Message-Id: <4637A4B5-F27E-488B-90E8-31B9A5DF2AAD@freebsd.org> References: <53dfb7a3.5e19.37746e44@svn.freebsd.org> <20140805041657.A1066@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 22:36:41 -0000 Il giorno 04/ago/2014, alle ore 14:01, Bruce Evans = 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 . But it is defined in , 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 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