Date: Thu, 23 Jun 2011 18:05:56 -0400 From: Garance A Drosehn <gad@FreeBSD.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-fs@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org> Subject: Re: [rfc] 64-bit inode numbers Message-ID: <4E03B8C4.6040800@FreeBSD.org> In-Reply-To: <20110623081140.GQ48734@deviant.kiev.zoral.com.ua> References: <20101201091203.GA3933@tops> <20110104175558.GR3140@deviant.kiev.zoral.com.ua> <20110120124108.GA32866@tops.skynet.lt> <4E027897.8080700@FreeBSD.org> <20110623064333.GA2823@tops> <20110623081140.GQ48734@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/23/11 4:11 AM, Kostik Belousov wrote: > On Thu, Jun 23, 2011 at 09:43:33AM +0300, Gleb Kurtsou wrote: > >> On (22/06/2011 19:19), Garance A Drosehn wrote: >> >>> Sorry for replying to an older message, but a reply made in a different >>> thread reminded me about this project... >>> >>> Also, I may have asked this before. In fact, I'm almost sure that I started >>> a reply to this back in Jan/Feb, but my email client claims I never replied >>> to this topic... >>> >>> Are you increasing only the size of ino_t, or could you also look at >>> increasing the size of dev_t? (just curious...) >>> >> Sure. Incorporating as much of similar changes as possible is good. >> I've added Kostik and Matthew to CC list, it's for them to decide. >> >> dev_t on other OSes: >> NetBSD - uint64_t >> DragonFly - uint32_t >> Darwin - __int32_t >> OpenSolaris - ulong_t >> Linux - __u32 >> >> Considering this I think 3rd party software is not ready for such >> change. >> >> Major/minor mapping to dev_t will get more complicated. >> >> And the most important question: what would you want it for? [...] >> > Indeed, this is the right question. > Consider the thread "Increasing the size of dev_t and ino_t" from freebsd-arch in 2002: http://docs.freebsd.org/mail/archive/2002/freebsd-arch/20020317.freebsd-arch.html In particular, this message by Robert Watson: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=139853+0+archive/2002/freebsd-arch/20020317.freebsd-arch I just participated in an online conference for OpenAFS, and while it isn't exactly taking the world by storm, I keep thinking it would be useful if FreeBSD could map individual AFS volumes to unique dev_t identifiers. And given the way AFS is implemented (as a global filesystem with many cells all reachable at the same time), and given the way most sites deploy AFS (with thousands or tens-of-thousands of individual AFS volumes *per site*), that adds up to a lot of values for dev_t. The upcoming release of OpenAFS should include a working and pretty stable AFS client for FreeBSD, so having a larger dev_t would have a more immediate application than it did back in 2002. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E03B8C4.6040800>