Daniel Hazelbaker wrote:
> On 3/20/03 8:26 AM, "didier" <dgautheron@...> wrote:
>
>
>>Daniel E. Lautenschleger wrote:
>>
>>>Does this have anything to do with the post I sent the other day? See
>>>below:
>>>
>>
>>Yes If you are using multiple connections for the copy, no if the volume
>>have only one client. In 1.6.1 id allocation is not atomic.
>>
>>Didier
>
>
> Could you elaborate on this a bit? I am not sure I understand what you mean
> by "multiple connections for the copy"? How can you have multiple
> connections going for a single copy?
With two Macs mounting the same volume and copying different folders to
it, for example if Macs are on a 100Mbits switch and servers on 1 Gbits
port, with two Macs it will be roughly two time faster.
I am curious because every time I try
> to backup my file server (either by copying files off or using retrospect
> network backup) it errors at some point. With file copy I forget what the
> error is but with retrospect it eventually says that files/directories have
> duplicate DID numbers.
Without cnid
- if you have more than 65536 files you always get duplicate DID.
With cnid
- if you have hardlinks or in some cases symlinks.
- with AFP concurrent access (should be better with CVS HEAD) or with
local/SMB access you can get ID reused but you should not get duplicate,
but you are not backuping an active volume, aren't you?
The reason is that local/access SMB don't update the cnid DB when they
move a file, so on a cnid lookup we search by device/inode and if we
have a match we reuse the record, update the filename, parent directory
id in it and so on. But we can't make the diff between a file moved and
a delete follow by a new file created using the same inode.
For AFP in 1.6 it's because the file is fully deleted when the
cnid_delete function is called so a second process may already reused
the inode ,unlikely? no because we have a 'sleeping disorder' with cnid
code under load :(.
In HEAD we keep an open descriptor until the end and when we close it,
ie when the OS frees the inode, the object and cnid record are gone.
There's a case me must take care of, though. When the inode is reused
for a different type eg a directory is deleted and the inode is reused
for a file. I'm sure Macs hate this one.
- a bug in cnid code, what filesystem do you use, XFS? Do you use
codepage option?.
Didier
|