Date: Mon, 06 Jun 2005 07:46:29 -0600 From: Scott Long <scottl@samsco.org> To: Garance A Drosihn <drosih@rpi.edu> Cc: Suleiman Souhlal <ssouhlal@freebsd.org>, current@freebsd.org, fs@freebsd.org Subject: Re: [PATCH] IFS: Inode FileSystem Message-ID: <42A453B5.3020006@samsco.org> In-Reply-To: <p06210238bec98dba5697@[128.113.24.47]> References: <82ACAD58-B179-44E2-852F-60F25C0BBBC1@FreeBSD.org> <20050606033145.GA80739@www.portaone.com> <42A3D6CF.2000504@samsco.org> <0A6C1F19-A734-4EC8-BE97-2D000D189968@FreeBSD.org> <p06210238bec98dba5697@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
Garance A Drosihn wrote: > At 1:05 AM -0400 6/6/05, Suleiman Souhlal wrote: > >> >> On Jun 6, 2005, at 12:53 AM, Scott Long wrote: >> >>> It's a huge win for CPU overhead in the filesystem, especially >>> when we start talking about increasing the size of m_links >>> field and possibly going 64-bit inode numbers. >> >> >> Talking about going to 64-bit inode numbers, how would we deal >> with the change in stat(2)? > > > By making some sort of incompatible change to stat(2). This has > been discussed from time-to-time. It's another change that I > would have liked to have seen (at least for the stat routines) > in 6.0, but right now I suspect it will not happen until 7.0. > We can't go making incremental incompatibilities to the filesystem without a good deal of planning. This is the type of thing that would go into a 'UFS3'. I have some long-term plans here, but I need to get the initial proof-of-concept journalling working before I start to seriously consider what else would be in UFS3. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42A453B5.3020006>