Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 May 2008 08:21:29 -0500
From:      Eric Anderson <anderson@freebsd.org>
To:        ticso@cicely.de
Cc:        freebsd-fs@freebsd.org
Subject:   Re: Consistent inodes between distinct machines
Message-ID:  <F4314D7D-2075-4167-8E58-590B764B7DE9@freebsd.org>
In-Reply-To: <20080503125050.GG40730@cicely12.cicely.de>
References:  <48070DCF.9090902@fsn.hu> <4CA7BA82-E95C-45FF-9B94-8EF27B6DB024@freebsd.org> <20080503125050.GG40730@cicely12.cicely.de>

next in thread | previous in thread | raw e-mail | index | archive | help

On May 3, 2008, at 7:50 AM, Bernd Walter wrote:

> On Fri, May 02, 2008 at 03:40:11PM -0500, Eric Anderson wrote:
>> On Apr 17, 2008, at 3:43 AM, Attila Nagy wrote:
>>
>>> Hello,
>>>
>>> I have several NFS servers, where the service must be available
>>> 0-24. The servers are mounted read only on the clients and I've
>>> solved the problem of maintaining consistent inodes between them by
>>> rsyncing an UFS image and mounting it via md on the NFS servers.
>>> The machines have a common IP address with CARP, so if one of them
>>> falls out, the other(s) can take over.
>>>
>>> This works nice, but rsyncing multi gigabyte files are becoming more
>>> and more annoying, so I've wondered whether it would be possible to
>>> get constant inodes between machines via alternative ways.
>>
>>
>> Why not avoid syncing multi-gigabyte files by splitting your huge FS
>> image into many smaller say 512MB files, then use md and geom concat/
>> stripe/etc to make them all one image that you mount?
>
> Where would be the positive effect by doing this?
> FFS distributes data over the media, so all the small files changes
> in almost every case and you have to checksum-compare the whole  
> virtual
> disk anyway.
> With multiple files the syncing is more complex. For example a normal
> rsync run can garantie that you get a complete file synced or none
> at all, but this doesn't work out of the box with multiple files, so
> you risk half updated data.


The positive effect is when your image size is smaller than the  
cylinder group size, so every image is not getting changes. The  
smaller your image, the better the efficiency, but the more difficult  
the concat becomes.

Possibly another way is to mirror devices over a ggate or iscsi link.

Eric





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F4314D7D-2075-4167-8E58-590B764B7DE9>