Date: Thu, 20 Jan 2011 14:41:08 +0200 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: [rfc] 64-bit inode numbers Message-ID: <20110120124108.GA32866@tops.skynet.lt> In-Reply-To: <20110104175558.GR3140@deviant.kiev.zoral.com.ua> References: <20101201091203.GA3933@tops> <20110104175558.GR3140@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
I've updated the patch. New version is available here: https://github.com/downloads/glk/freebsd-ino64/freebsd-ino64-patch-2011-01-20.tgz Changelog: * Add fts, ftw, nftw compat shims in libc * Place libc compat shims in separate files, don't hack original implementations. * Fix dump/restore * Use ino_t in UFS code (suggested by Kirk McKusick) * Keep ufs_ino_t (32 bit) for boot2 not to increase size On (04/01/2011 19:55), Kostik Belousov wrote: > I think some more comments for each patch in the set, in addition to > the one-line title, would be useful. > > No need to add regen patches, they only confuse the reader. Just add a > note to other patches where the regen is needed. > > I have big doubts about 0009, since struct inoref is not on-disk struct. Thanks. > My impression is that the issue of extending ino_t to 64 bit is much bigger > then presented in your patch. E.g. FTSENT (include/fts.h) explicitely > include ino_t member. As result, there are more ABI changes that handled. > Or, did I missed this in the patchset ? I've missed this one, and also ftw/nftw. > Might be, libarchive and libufs are also affected. Not sure about struct > pidfh from libutil. There is no symbol versioning in these libraries, SHLIB_MAJOR should be dumped (for all libraries in the tree). Thanks, Gleb.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110120124108.GA32866>