I suggest that we get together soon for a "dnode summit", if you will,
in which we put our various plans on the whiteboard and attempt to do
the global optimization. I suspect that Lustre and pNFS, for example,
have very similar needs -- it would be great to make them identical.
The dnode is a tr
Mark Shellenbaum wrote:
> Andreas Dilger wrote:
>> On Sep 17, 2007 08:31 -0600, Mark Shellenbaum wrote:
>>> While not entirely the same thing we will soon have a VFS feature
>>> registration mechanism in Nevada. Basically, a file system registers
>>> what features it supports. Initially this w
Andreas Dilger wrote:
> On Sep 17, 2007 08:31 -0600, Mark Shellenbaum wrote:
>> While not entirely the same thing we will soon have a VFS feature
>> registration mechanism in Nevada. Basically, a file system registers
>> what features it supports. Initially this will be things such as "case
>
On Sep 17, 2007 08:31 -0600, Mark Shellenbaum wrote:
> While not entirely the same thing we will soon have a VFS feature
> registration mechanism in Nevada. Basically, a file system registers
> what features it supports. Initially this will be things such as "case
> insensitivity", "acl on cr
Andreas Dilger wrote:
> I agree, but I suspect large dnodes could also be of use to ZFS at
> some point, either for fast EAs and/or small files, so we wanted to
> get some buy-in from the ZFS developers on an approach that would
> be suitable for ZFS also. In particular, being able to use the lar
> There are several issues that I think should be addressed with a single
> design, since they are closely related:
> 0) versioning of the filesystem
> 1) variable dnode_phys_t size (per dataset, to start with at least)
> 2) fast small files (per dnode)
> 3) variable znode_phys_t size (per dnode)
>
