DragonFly BSD
DragonFly hammer List (threaded) for 2010-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: pfs softlinks


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 5 Apr 2010 08:49:18 -0700 (PDT)

:Hey,
:
:> Regular softlinks (e.g. from snapshots) resolve correctly, but for PFS
:> softlinks, the b-tree search won't return anything. What are the
:> parameters I need to set?
:
:Ok I got it! The question is not "pfs or regular softlink", but whether
:the softlink target name exceeds a certain length. For short names (<=
:24 chars), the target name can be found in the `struct
:hammer_inode_data', for longer names a data block has to be retrieved.
:
:PFS links still won't resolve correctly, though. I'm getting this:
:
:   lrwxr-xr-x  0 root  wheel  10 Jun  7  2009 master -> @@PFS00001
:
:instead of:
:
:   lrwxr-xr-x  0 root  wheel  10 Jun  7  2009 master ->
:@@0xffffffffffffffff:00001
:
:`hammer_vop_readlink' seems to do some dort of pfs-lookup. I'm working
:on it :)
:
:Daniel

    Ah.  I should have guessed that was what it was.  Yes, you figured
    it out.

    The actual softlink is, in fact, "@@PFS00001".  HAMMER detects
    the special name and expands it to the transaction-id for the
    actual PFS.

    See line 992 hammer_vnops.c and also around line 1730.

    The reason we have to do this is primarily for slave PFSs whos
    snapshot transaction id changes as the mirroring code updates
    the slave.  The softlink has to change with it so when you CD
    into the softlink you get the 'latest' snapshot.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]