Yes, NFSv3 client side locking works pretty well so long as no shared concurrent write happens. A single node's os would assume successful lock for it to write to a file, when multiple nodes do this concurrently, the file will be corrupted. As with stack it can happen and rendering the tool unusable. But NFSv4 server side locking can leave dead locks appear live, leading stack to wait forever. So we stay client side locking, and carefully have each node use different path on the shared storage for .stack folders, then reinitialize it in case corrupted by accident.

On 2021-02-25, at 23:59, Sven Panne wrote:

Am Do., 25. Feb. 2021 um 15:59 Uhr schrieb Olaf Klinke mailto:olf@aatal-apotheke.de>: Speaking of which, is there a specification about what filesystem features stack and its sub-tools expect? I can not build stack projects on a remote cifs share, but on the local filesystem it works fine. The error is

Encountered error while migrating Stack database: SQLite3 returned ErrorBusy while attempting to perform step: database is locked Please report this on https://github.com/commercialhaskell/stack/issues https://github.com/commercialhaskell/stack/issues [...]

In ancient times, locking over NFS didn't work, or at least not reliably. With NFS 4, locking was added to the protocol IIRC, but I have no clue how good it works, especially when you mix various platforms/implementations. What the current state with CIFS regarding locking is: I don't know, but in general I don't really trust remote file systems in this area. :-} _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On 25/02/2021 22.26, Olaf Klinke wrote:

So what exactly is "locking" on the file-system level, then? I searched and found the term "oplocks" and that this is an option for cifs. Which state does stack need? oplock=on or oplock=off? My SMB server currently has oplock=on. Tried toggling it, still same SQLite3 locking error.

I have no clue about stack internals, but I suspect that the only requirements regarding file system semantics are really the requirements of SQLite3. (Which is obviously what you're seeing.)

It's a pity, my approach was to have as much of my Haskell stuff on a NAS as possible, so I wouldn't run into disk space issues. But this and the fact that stack/ghc stubbornly insist on using local dirs like /tmp make this hard. Has anynone else here successfully built a stack project on a cifs share?

Judging by the output from $ strings `which stack`|grep TMP I'm guessing you could convince the embedded SQLite3 to use a different temporary directory by setting the SQLITE_TMPDIR env var. Not sure if there are other variables of interest there. (I'm assuming you're already setting STACK_ROOT and/or your $HOME is already on the network drive.) Setting TMPDIR=/foo is respected by *many* programs, not sure about whether GHC/Cabal do.

P.S.: Yes, I even re-mapped /tmp to another partition once to bootstrap ghc because it would occupy my entire tmpfs. But it would be nice if one could do without such tricks.

Yeah, it's a bit of a sad state of affairs that there is only one "TMPDIR" variable while there are typically /tmp -> backed by RAM /var/tmp -> backed by disk on modern Linux systems. Regards,