[PATCH v2] File Server Remote VSS Protocol server
ddiss at suse.de
Tue Mar 24 08:07:11 MDT 2015
On Tue, 24 Mar 2015 14:32:39 +0100, Volker Lendecke wrote:
> > I agree that tdb_pack/unpack is a pretty ugly interface, and I'm fine
> > with using idl for [un]marshalling. As mentioned though, I don't think
> > this should be a show-stopper for merging this feature - conversion to
> > IDL should be possible without a change to the on-disk format.
> Wouldn't this mean that we have to teach PIDL about the format
> tdb_pack/unpack uses?
Yes. Which would be desired anyway, for other in-place tdb_pack->IDL
> The reason why I jumped on this is that this will be
> another fresh piece of code that will have to be converted when someone
> wants to get rid of tdb_pack. We already have data upgrade procedures
> all over the place, for example in pdb_tdb. Whenever I look at those I
> get the impression that we can never ever get rid of this code, although
> it is neither well tested nor in use at all anywhere anymore. If we know
> that we want to change the data format soon, I would hesitate to create
> new data files with an already deprecated format.
Fair enough. On that, couldn't we consider mandating that upgrades are
only supported if they're done from versions >= X versions behind the
latest? E.g. users would need to go via an intermediary version if they
wish to upgrade from something really old.
> > The database is only manipulated by the single FSRVP server process, so
> > this shouldn't be an issue.
> Ok, I did not see that this is single-process single thread.
MS-FSRVP mandates that "Windows servers allow only one shadow copy set
to be going through the creation process", making the current single
process architecture good enough for now.
More information about the samba-technical