On Fri, 13 Mar 2009 17:42:20 +0100, [email protected] wrote:
> Hi,
> 
> > Basically I believe this is possible, but one problem is how to
> > realize rollback of the remote nilfs which will become required when
> > allowing user's updates or garbage collection on the remote device
> > after synchronization.
> 
> let's call them master / slave, I'm confused which one is remote :)
> 
> I assume only the master is writable and slaves don't do any changes or
> cleaning.

If that premise is allowed, things would become so simple.  But, is it
suitable for practical use?

If cleaning is not allowed, the slave partition gets full
periodically.  So, frequent full replications would be needed in that
case.

If we supposed to have very huge slave device, breaking the constraint
could be costly because recovery to the slave state requires a full
replication.
 
> Require that all checkpoints from last sync to present are still existing.
> Upon dump on master, cleanerd has to be suspended and may resume after
> dump. Does that make things easier?

Yes, absolutely.  I have no mind to think the dumping while cleanerd
operates.

The dump tool at least should hold write lock for .nilfs to prevent
cleaning, and I would make the tool so that it suspends and resumes
cleanerd by signals (if I were).

> By the way: When I completely disable cleanerd on the master, wouldn't it
> be possible to define a byte-range on the block device which makes up the
> difference between two checkpoints and copy that to the slaves?

We would get multiple ranges on the device not a single range because
nilfs may allocate segments in non-sequential order.  (Though the
current cleanerd algorithm induces fifo order allocation, it is not
guranteed by nilfs.)

The current sufile doesn't have information on the sequence (or chain)
of allocated segments.  So, it requires scanning of on-disk segment
headers; each on-disk segment header has a next pointer.

If the scanning cost becomes an issue, we can include the next pointer
in sufile to minimize the cost.
 
Regards,
Ryusuke Konishi
_______________________________________________
users mailing list
[email protected]
https://www.nilfs.org/mailman/listinfo/users

Reply via email to