DragonFly hammer List (threaded) for 2010-04
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: pfs softlinks
: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]