I don't think NFS should be a problem. I am involved in an installation using fossil on NFS with over 300 fossils synced between 3 sites. Some 300 users have access but I'm not sure how many are actively accessing the repos. All fossils are accessed via NFS so collisions happen all the time. People know to just try again on the occasional update fail due to a busy fossil. A more graceful fail or better yet a wait and retry would be nice but recovery is as simple as up-arrow, enter.
Fossil isn't perfect (I'd love to see fossil mv behave the same as Unix mv) but NFS has generally not been an issue. I'v not seen this error and it might be either a regression or new issue. In short, I think fossil usually works fine on NFS. The caveat might be *which* NFS. We see different NFS issues with sqlite3 locking depending on what tier or vendor your server is. Aside: on my home system I use fossil on MooseFS which has worse locking than NFS. Performance is slower than running on local disk but still in the sub second range for most operations. So long as you don't access the fossil file simultaneously from two different hosts there are no locking or crashing issues that I've seen. This is all with version 1.25. On Mon, Jul 15, 2013 at 5:27 AM, Stephan Beal <sgb...@googlemail.com> wrote: > On Mon, Jul 15, 2013 at 2:08 PM, Richard Hipp <d...@sqlite.org> wrote: > >> >> >> On Mon, Jul 15, 2013 at 7:39 AM, Stephan Beal <sgb...@googlemail.com>wrote: >> >>> Hi, all, >>> >>> i have just installed a fossil repo on a company-internal Linux server >>> and i am seeing a weird new error message at the top of all pages: >>> >>> error code 28: file renamed while open: /.../bss-scripts.fsl >>> >> >> This is a warning message that the SQLite core issues if the inode number >> of the database file changes. A change in the inode number can be an >> indicator that a database file has been renamed while it is in use, which >> can lead to database corruption. Or, it might just indicate that the >> database is on NFS. >> >> You'll be much much happier with the performance if you put the >> repository on a local filesystem, btw. >> > > > i would rather gnaw off my foot than hassle with having a DB on an NFS, i > just wasn't aware until after the fact that i was even on NFS :/. So, > problem solved by simply moving the repo file into the local FS. > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority...
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
