You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Dr. Folkert Janssen" <Fo...@web.de> on 2008/10/08 11:41:03 UTC
Reliablilty of FSFS on MS Windows network shared drives
Dear List!
I understand that FSFS has to be used when a network share is intended
to hold a repository accessed with svnserver. A large number of
contributions on the net indicate that this setup is used quite
frequently.
My question now is if the standard MS Windows network share is reliable
enough for hosting a repository keeping its many quirks in mind. Is FSFS
capable of reporting a commit reliably under these circumstances?
Any answer is highly appreciated.
Regards,
Folkert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Reliablilty of FSFS on MS Windows network shared drives
Posted by "Dr. Folkert Janssen" <Fo...@web.de>.
> Backing up the disc containing a repository isn't a good idea: the backup
> could be in an inconsistent state
Agreed, Ducan. My assumption was that no changes would go into the repository at back-up time. But you are absolutely right. Replicating the backups instead comes at no additional cost.
Thank you for your reply.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Reliablilty of FSFS on MS Windows network shared drives
Posted by communitybot <co...@googlemail.com>.
>
> It will be great if you can share the HOTCOPY script that make hotcopy on a
> separate machine with users list.
Sure. The NFS share is permanently mounted via /etc/fstab, so it's just
like doing a local hotcopy - nothing special about it.
#! /bin/bash
# Backup and repository locations - set these to match your location
backupshare=/MyNFSBackupShare
backupdir=${backupshare}/mybackup
rootrepodir=/home/svn
repodir=${rootrepodir}/src
# Create temporary backup dir
mkdir -p $backupdir
# Do the hotcopy
svnadmin hotcopy $repodir ${backupdir}/src
# Include the .dav_svn.passwd file in the backups
cp ${rootrepodir}/.dav_svn.passwd $backupdir
# Create a tar archive of the backup
tar cf ${backupshare}/mybackup.tar ${backupdir}
# Remove the temporary directory
rm -rf $backupdir
2008/10/24 Rafiuddin M K <ra...@gmail.com>
>
> It will be great if you can share the HOTCOPY script that make hotcopy on a
> separate machine with users list.
>
>
>
> On 10/24/08, communitybot <co...@googlemail.com> wrote:
>>
>>
>>
>>
>>> But yes, if you have the disk space to do a complete hot copy before
>>> doing the backup it may help your recovery effort.
>>>
>>
>>
>> We do the hotcopy on an NFS share which is included in the tape backups.
>> This means we have an online hotcopy on a separate machine and don't need so
>> much disk space on the Subversion server.
>>
>>
> -- With Best Wishes,
> Rafiuddin MK
>
Re: Reliablilty of FSFS on MS Windows network shared drives
Posted by Rafiuddin M K <ra...@gmail.com>.
It will be great if you can share the HOTCOPY script that make hotcopy on a
separate machine with users list.
On 10/24/08, communitybot <co...@googlemail.com> wrote:
>
>
>
>
>> But yes, if you have the disk space to do a complete hot copy before
>> doing the backup it may help your recovery effort.
>>
>
>
> We do the hotcopy on an NFS share which is included in the tape backups.
> This means we have an online hotcopy on a separate machine and don't need so
> much disk space on the Subversion server.
>
>
-- With Best Wishes,
Rafiuddin MK
Re: Reliablilty of FSFS on MS Windows network shared drives
Posted by communitybot <co...@googlemail.com>.
> But yes, if you have the disk space to do a complete hot copy before
> doing the backup it may help your recovery effort.
>
We do the hotcopy on an NFS share which is included in the tape backups.
This means we have an online hotcopy on a separate machine and don't need so
much disk space on the Subversion server.
Re: Reliablilty of FSFS on MS Windows network shared drives
Posted by km...@rockwellcollins.com.
"Dr. Folkert Janssen" <Fo...@web.de> wrote on 10/23/2008
01:42:55 AM:
> > Backing up the disc containing a repository isn't a good idea: the
backup
> > could be in an inconsistent state
>
> Agreed, Ducan. My assumption was that no changes would go into the
repository
> at back-up time. But you are absolutely right. Replicating the backups
> instead comes at no additional cost.
I believe 1.5 made some svnadmin verify changes to "fix" an inconsistently
backed-up FSFS repository. In reality, the only thing that can
be "wrong" is the current index number, which can be manually fixed if
needed.
But yes, if you have the disk space to do a complete hot copy before
doing the backup it may help your recovery effort.
Kevin R.
Re: Reliablilty of FSFS on MS Windows network shared drives
Posted by "Dr. Folkert Janssen" <Fo...@web.de>.
> Backing up the disc containing a repository isn't a good idea: the backup
> could be in an inconsistent state
Agreed, Ducan. My assumption was that no changes would go into the repository at back-up time. But you are absolutely right. Replicating the backups instead comes at no additional cost.
Thank you for your reply.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Reliablilty of FSFS on MS Windows network shared drives
Posted by Duncan Booth <du...@suttoncourtenay.org.uk>.
"Dr. Folkert Janssen" <Fo...@web.de> wrote:
> The idea is to either run svnserve on one host and having it access a
> repository on a network share, or to run svnserve with a repository on
> the same host and replicate that to a share. We end up having a backuped
> repository either way but which way is to be preferred?
Backing up the disc containing a repository isn't a good idea: the backup
could be in an inconsistent state. What you should do is put the repository
on a non-backed up local disc and then create regular snapshots to your
network disc which is backed up. Use a script such as hot-backup.py to
create the backups.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Reliablilty of FSFS on MS Windows network shared drives
Posted by "Dr. Folkert Janssen" <Fo...@web.de>.
Ryan,
Sorry for the delayed answer. It seems that my former reply has not made
it into the list ... this is why I post it again ... Here is what I
worte:
On Wed, 2008-10-08 at 18:30 -0500, Ryan Schmidt wrote:
[...]
> In Subversion the file:/// protocol is not designed
> for serious multiuser use; it's meant for testing only.
> If the goal is to have one server serve the repository via svnserve
> while it's physically housed on another server's disk, why add this
> complexity? Just host the repository on the server that has the
> sufficient disk space.
[...]
Thank you for your reply Ryan,
The reason is, that we only have backups for network drives that are
provided by a dedicated server. So we cannot run svnserve on the host
prividing the shares and the hosts we can run svnserve cannot be
backup-ed.
The idea is to either run svnserve on one host and having it access a
repository on a network share, or to run svnserve with a repository on
the same host and replicate that to a share. We end up having a backuped
repository either way but which way is to be preferred?
Hence the question ...
--Folkert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Reliablilty of FSFS on MS Windows network shared drives
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 8, 2008, at 06:41, Dr. Folkert Janssen wrote:
> I understand that FSFS has to be used when a network share is intended
> to hold a repository accessed with svnserver. A large number of
> contributions on the net indicate that this setup is used quite
> frequently.
> My question now is if the standard MS Windows network share is
> reliable
> enough for hosting a repository keeping its many quirks in mind. Is
> FSFS
> capable of reporting a commit reliably under these circumstances?
I must ask why you want to do this.
If the goal is to have a Windows file server host the repository, and
have multiple users commit to it using file:/// URLs to that file
server, then I must instead recommend you set up svnserve on the
Windows server instead and access the repository through svnserve's
svn:// protocol. In Subversion the file:/// protocol is not designed
for serious multiuser use; it's meant for testing only.
If the goal is to have one server serve the repository via svnserve
while it's physically housed on another server's disk, why add this
complexity? Just host the repository on the server that has the
sufficient disk space. This will be faster and will eliminate any
potential problems you may encounter due to network shares.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org