From owner-freebsd-fs@FreeBSD.ORG Sun Nov 23 02:17:20 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52084355; Sun, 23 Nov 2014 02:17:20 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D22A82D2; Sun, 23 Nov 2014 02:17:19 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIEALlCcVSDaFve/2dsb2JhbABcg2NZBIMCyQ8KhhVVAoEXAQEBAQF9hAMBAQQBAQEgKyALGxgCAg0ZAikBCSYGCAcEARwEiCANtxyWGAEBAQEBAQEBAQEBAQEBAQEBAQEBGIEtjT6BTwEBGzQHgnmBVQWMJYsohCeEQT+DGogYgi+DPIQKggIggXkqMAeBCDmBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,440,1413259200"; d="scan'208";a="171786986" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 22 Nov 2014 21:17:18 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 166A3B3F91; Sat, 22 Nov 2014 21:17:18 -0500 (EST) Date: Sat, 22 Nov 2014 21:17:18 -0500 (EST) From: Rick Macklem To: Gleb Kurtsou Message-ID: <1070528800.5649836.1416709038079.JavaMail.root@uoguelph.ca> In-Reply-To: <20141123015021.GA1658@reks> Subject: Re: RFC: patch to make d_fileno 64bits MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Nov 2014 02:17:20 -0000 Gleb Kurtsou wrote: > On (21/11/2014 19:33), Rick Macklem wrote: > > Gleb Kurtsou wrote: > > > On (21/11/2014 10:25), John Baldwin wrote: > [...] > > > > > > > > I think this is already done (along with several other changes) > > > > more fully in > > > > the projects/ino64 branch in svn? > > > > > > projects/ino64 was created by mdf for merging GSoC commits, and > > > it > > > didn't even get half way through. > > > > > > I'm currently working on merging the code to CURRENT. It's been > > > more > > > than 2 years, so there is quite some work in there. I intend to > > > update > > > the branch as soon as code is ready for review. > > > > > Btw, I just took a quick look and I didn't find any changes to > > "struct dirent" > > in projects/ino64, so I think my original assumption that this > > piece of the > > puzzle hadn't yet been solved, is correct. (Gleb, if you had > > changes to > > "struct dirent" and related fs changes, please let me know.) > > projects/ino64 was created for merging GSoC commits. The branch is > incomplete to say the least.. There are preparatory changes in there > only. In case you are interested please refer to > https://github.com/glk/freebsd-ino64/commits/projects/ino64 > > BTW original GSoC branch also changes VOP_READDIR for all file > systems > to populate dirent.d_off. > > I've attached the patch for some of the system headers generated by > git diff -r 531f5069a9b0f61b8ecd08e4ed744cec3b022606 -r > github/projects/ino64 sys/sys/{_types,dirent,mount,stat}.h > > ~/ino64-sys-sys.patch > > > > > Oh, and thanks to some comments, the new struct dirent has already > > changed to: > > > > struct dirent { > > __uint64_t d_cookie; /* dir cookie for next dir entry */ > > __uint64_t d_fileno; > > __uint16_t d_reclen; > > __uint8_t d_type; > > __uint8_t d_namlen; > > __uint8_t d_pad[4]; /* align d_name to 8 byte boundary */ > > __uint8_t d_name[MAXNAMLEN + 1]; > > }; > > GSoC'2011 code: > struct dirent { > ino_t d_fileno; /* file number of entry */ > off_t d_off; /* next entry seek offset */ > __uint16_t d_reclen; /* length of this record */ > __uint16_t d_namlen; /* length of string in d_name */ > __uint8_t d_type; /* file type, see below */ > __uint8_t d_unused1; > __uint16_t d_unused2; > char d_name[MAXNAMLEN + 1]; /* name must be no longer than this */ > }; > Hmm. I actually was wondering if d_namlen should go to uint16_t just in case someone wanted to make MAXNAMLEN > 255 someday. I think your variant is better than mine. I'll try and take a look at the git stuff (never done git, but I guess I can't avoid it forever). Thanks for the pointer, rick > > > > It was pointed out that C would pad the structure to a multiple of > > 8 bytes > > for some arches and without d_pad that would imply d_name wasn't at > > the end > > of the structure. (Apparently code somewhere find d_name by > > subtracting MAXNAMLEN + 1 > > from sizeof(struct dirent) and this fails if d_name isn't at the > > end. Yuck, > > but the above fixes it.) > > > > However, the size of d_namlen could become uint16_t, if anyone > > thinks MAXNAMLEN > > might want to be greater than 255 someday (long away, since that's > > another ABI change). > > Somebody has already mentioned it previously so I've bumped it to > uint16 > back than. > > > > > > rick > > > > > Besides branch also changes dev_t to 64-bit, bumps MNAMELEN to > > > 1024 > > > and > > > has complete ABI compatibility shims (probably except openaudit > > > which > > > had > > > issues). > > > > > > > > > _______________________________________________ > > > freebsd-fs@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > To unsubscribe, send any mail to > > > "freebsd-fs-unsubscribe@freebsd.org" > > > >