Re: NetBSD hammer with fuse and hammerread

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
:On Thu, 16 Apr 2009, Jeremy C. Reed wrote:
:
:> Problems:
:> - doesn't have number of links for directory (maybe causes find problem 
:> 	shown below)
:
:I see on a DragonFly system using native hammer and also mounting the test 
:image, the number of links for a directory is always 1 (versus 0 I see 
:when using the fusehammer). On ufs, the links would show the correct 
:amount -- always more than 1 for ufs directories.
:
:Is this documented?

    Probably not.  HAMMER does not maintain a link count in the directory
    inode with regards to the number of directory entries, because it
    would require rewriting the directory inode whenever a directory entry
    is added or remove.  This is a very expensive operation for HAMMER
    (at least as currently implemented) so it just doesn't do it.

:> - doesn't have size of directory (number of blocks used)
:
:On a DragonFly system using native hammer and also mounting the test 
:image, the number of blocks used by the directory is always 0. (Where with 
:ufs it begins at 512.)
:
:Is this behaviour documented? Okay? Known?
:...

    The number of blocks is a faked number for directories.  Actually,
    for files too.  HAMMER doesn't keep track of the actual block
    allocations on a per-inode basis.

    In UFS a directory is an actual file on the media.  In HAMMER a
    directory is *NOT* a file on the media.  So I really have no idea
    what I should report in terms of file size.

    It should be noted that insofar as I know there is no standard that
    requires the directory link count to reflect the number of entries
    in the directory or that the st_size of the directory report anything
    real.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>