Re: an observation regarding FSFS performance on BTRFS
Out of curiosity, I built the 1.7.0 rc3 that's currently in preparation and tried it on both systems. The EXT4 system managed 200 revisions in the time it took the BTRFS system to complete 70, so the EXT4 system is about 3x faster for this particular test. It appears as if the server-side changes in 1.7.0 have reduced the performance penalty of using BTRFS in place of EXT4 for an FSF repository. // ben On Mon, Sep 12, 2011 at 18:07, Daniel Shahaf wrote: > 1.7 includes performance optimizations by Stefan2, new cache modules, > new cache users, etc. > > branches/performance includes, among other things, a file handles cache > for FSFS. The plan is to merge that for 1.8. > > branches/revprop-packing packs revprops into flat files (not to sqlite). > A basic form currently works and the final form will be included in 1.8. > > Ben Smith-Mannschott wrote on Mon, Sep 12, 2011 at 17:28:28 +0200: >> I'm using 1.6.x. I wasn't aware that there'd been sufficient >> server-side work in 1.7.x as to make this distinction important. >> >> // ben >> >> On Mon, Sep 12, 2011 at 16:12, Daniel Shahaf wrote: >> > You haven't mentioned what version of svn you use. As you say, there >> > has been work recently --- some of it is in 1.7, some of it is on >> > ^/subversion/branches/performance, some of it is on >> > ^/subversion/branches/revprop-packing, and some additional ideas >> > are in notes/fsfs-improvements.txt in trunk. >> > >> > Ben Smith-Mannschott wrote on Mon, Sep 12, 2011 at 15:44:20 +0200: >> >> I've made the observation that FSFS repositories perform better on >> >> EXT4 than BTRFS. This probably isn't ground-breaking, but I thought >> >> I'd share it. >> >> >> >> I've got two Linux machines: >> >> >> >> - colossus, using BTRFS spanned over two disks. >> >> 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 >> >> x86_64 x86_64 x86_64 GNU/Linux >> >> >> >> - oberon, using EXT4 on a 2-disk software RAID-1 set. >> >> Linux oberon 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC >> >> 2011 >> >> x86_64 GNU/Linux >> >> >> >> I've noticed that writes to FSFS repositories are 5x faster under EXT4 >> >> than BTRFS. When svnsyncing form the same svn:// source to an local >> >> repository (file://), oberon completes about 400 revisions in the time >> >> it takes colossus to grind through 80. >> >> >> >> The BTRFS machine is our build server. Performance with (1.6.x) >> >> working copies is quite acceptable, but I'm glad I'm not using it to >> >> host svn repositories. >> >> >> >> Looks like the BTRFS people have some work to do. Maybe current >> >> Kernels have already improved this picture. I know there has been >> >> recent work on reducing the cost of meta-data operations (e.g. file >> >> creation, ...) and that work is ongoing on defragmentation >> >> functionality because of poor performance on files that are modified >> >> in place heavily (e.g. sqlite). >> >> >> >> // ben >> > >
Apache Subversion 1.7.0-rc3 Released
I'm happy to announce the release of Apache Subversion 1.7.0-rc3. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#pre-releases (Note: It may take up to 24 hours for all mirrors to sync the release.) The SHA1 checksums are: 0a1e80426720233bfdb8aaab1d97e3e8bd3ae82c subversion-1.7.0-rc3.zip 37c44ac69b132749deece46f853fdbfbe4d8b417 subversion-1.7.0-rc3.tar.bz2 6c62df9f66a9eb71df055ad8794e887716cd04a6 subversion-1.7.0-rc3.tar.gz PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.7.0-rc3.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.7.0-rc3.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.7.0-rc3.zip.asc For this release, the following people have provided PGP signatures: C. Michael Pilato [1024D/1706FD6E] with fingerprint: 20BF 14DC F02F 2730 7EA4 C7BB A241 06A9 1706 FD6E Paul T. Burba [1024D/53FCDC55] with fingerprint: E630 CF54 792C F913 B13C 32C5 D916 8930 53FC DC55 Julian Foad [1024D/353E25BC] with fingerprint: 6604 5A4B 43BC F994 5728 351F 33E4 353E 25BC Hyrum K. Wright [1024D/4E24517C] with fingerprint: 3324 80DA 0F8C A37D AEE6 D084 0B03 AE6E 4E24 517C Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Johan Corveleyn [4096R/010C8AAD] with fingerprint: 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD Mark Phippard [1024D/035A96A9] with fingerprint: D315 89DB E1C1 E9BA D218 39FD 265D F8A0 035A 96A9 This is a release candidate for what will eventually become Apache Subversion 1.7.0. It is thought to be free of blocking issues, and if none are found will become the final release. For this reason, we encourage thorough testing in as many environments as possible. This release candidate continues the four-week "soak" period to allow for further testing, and barring show-stopping bugs, the final 1.7.0 release can be expected on or near Sept. 28. Even though we feel that this release is ready for widespread testing by the community, some things may still change before the final release. Of particular note, please remember than persistent data, such as the working copy or repository formats may change before the final release, and there may not be an upgrade path from the pre-releases to the final. As a note to operating system distro packagers: while we wish to have this release candidate widely tested, we do not feel that it is ready for packaging and providing to end-users through a distro package system. Packaging a release candidate poses many problems, the biggest being that our policy lets us break compatibility between the release candidate and the final release, if we find something serious enough. Having many users depending on a release candidate through their distro would cause no end of pain and frustration that we do not want to have to deal with. However, if your distro has a branch that is clearly labeled as containing experimental and often broken software, and explicitly destined to consenting developers and integrators only, then we're okay with packaging the release candidate there. Just don't let it near the end users please. Release notes for the 1.7.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.7.html You can find the list of changes between 1.7.0-rc3 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.7.0-rc3/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
cannot access folder though I have right
Though I am a member of the group "shortfall", and there are group access rights (rwS) for the folder db/rev/1, I cannot access it. I also have disabled the SELinux totally to isolate the problem. May anyone tell me why I cannot access the folder? Followings are the diagnostic info: [chensy@chen working]$ ls -l /home/svn/shortfall/db/revs/ total 8 -rw-rwS--- 1 chensy shortfall 115 Sep 13 13:04 0 -rw-rwS--- 1 root shortfall 2238 Sep 13 13:04 1 [chensy@chen working]$ more /home/svn/shortfall/db/revs/1 /home/svn/shortfall/db/revs/1: Permission denied [chensy@chen working]$ whoami chensy [chensy@chen working]$ getent group shortfall shortfall:x:525:chensy,lanhai [chensy@chen working]$ su - Password: [root@chen ~]# sestatus SELinux status: disabled -- All the best, Michael Chen
Lock Changes in a Project Tree
Hi, I need to lock the creation of directories in a project versioned with SVN. Authorized users can change and/or add archives, but when they try to add an directory, SVN block this commit. I know that this can be done with a pre-commit hook, but I have no ideia how can I do this. Any sugestions, please! Thanks -- Luis Augusto Silva Lima
Extra behaviour in a 1.4 to 1.6 2 url merge
Hi, I'm getting some weird extra behaviour during a 1.4 server, 1.4 repository and 1.6 client merge of a branch back to the trunk of my project - as in the thread http://svn.haxx.se/tsvnusers/archive-2010-10/0042.shtml - where a simple 2 URL merge produces extra output that doesn't appear in the same merge for 1.4/1.4/1.4 server/repos/client or 1.6/1.6/1.6. This happens following a merge of trunk changes to the branch. It produces the extra information (for example): Merging r5 through r52 svn://my_repos/project_name_svn/trunk (some file information) Reverse-merging 50 through 5 (some extra operations on files) where the extra operations undo the trunk operations since that point. The upshot is that all the modifications in the trunk since the branch was created are undone in the working copy following the merge back from the branch, which is a nasty side effect. This doesn't happen in the pure 1.4 or pure 1.6 cases, and doesn't occur when you use the --ignore-ancestry option, which isn't really a reliable solution. I'm using the 1.6.16 release. Other than upgrading the server/repository, which will take some time (I don't control it), I'd be grateful if anyone had a solution or explanation. Cheers, Ben Fitzpatrick
How to fix corrupt revision in repo?
Greetings, I have an SVN repo that is failing svnadmin verify on revision 192. For some reason the verify output says: [...various successful revisions...] * Verified revision 191. svnadmin: Can't read file 'E:\Repositories\Client_Name\db\revs\0\16 2': End of file found I'm not sure why the verification command for revision 192 would throw an error description for revision 162. Revision 192 affected a completely different part of the repository to revision 162, so there is no obvious relationship between them. All the revisions from 193 to 332 (HEAD) are ok. It might be a one-off. This looks like a FSFS-backed repository (I am very new to SVN and inherited the server from someone else!). The server is VisualSVN 2.1.4, which is based on SVN 1.6.13. The clients are mostly TortoiseSVN 1.6.16, which uses SVN 1.6.17. What steps should I take to fix the corrupted revision? Is there more information that I should provide? (eg a copy of the rev 192 file?) This problem is causing checkouts and updates to fail for files that were last modified in that revision. Regards, David Hopkins Serck Controls = PRIVACY AND CONFIDENTIALITY NOTICE = The information contained in this message is intended for the named recipient only. It may contain privileged and confidential information. If you are not the intended recipient, you must not copy, distribute, take any action in reliance on it, or disclose any details of the message to any person, firm or corporation. If you have received this message in error, please notify the sender immediately by reply e-mail and delete all copies of this transmission together with any attachments. The views or opinions expressed in this e-mail or any attachment are not necessarily those of Serck Controls Pty Ltd. NOTE - You should carry out your own virus checks before opening any attachment.
RE: cannot access folder though I have right
> Subject: cannot access folder though I have right > > Though I am a member of the group "shortfall", and there are > group access rights (rwS) for the folder db/rev/1, I cannot > access it. I also have disabled the SELinux totally to Stupid question: Did you logout and login after you have added yourself to the shortfall group? Best regards / Freundliche Grüsse Wenzel Metromec AG Andreas Tscharner -- Andreas Tscharner, Development Wenzel Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland phone: +41 (0)81 257 07 00 fax:+41 (0)81 257 07 01 e-mail: mailto:andreas.tschar...@metromec.ch www:http://www.metromec.ch Open House am 26. und 27.10.11 Am 26. und 27. Oktober 2011 findet das Wenzel Metromec Open House in Chur statt. Tauchen Sie ein in interessante Fachreferate und Workshops. Besichtigen Sie topaktuelle Exponate aus dem Hause WENZEL. Erfahren Sie mehr über unsere Produkte und Dienstleistungen. Lernen Sie die neuste Version von Metrosoft QUARTIS kennen. Reservieren Sie sich das Datum. Das detailierte Programm folgt in Kürze.
