On Thu, 25 Jan 2018 19:45:55 +0000, Guillermo Rozas wrote: > --f403045fc0c6d76a7505639f07c8 > Content-Type: text/plain; charset="UTF-8" > > Hi, > which are the NFS options you're using to mount the drive? I had similar > problems, not related to darktable but to the NFS mounts work. In short: if > you hard mount an NFS share (the default) any problem server-side means the > applications trying to use it hang. It's like if the hard drive froze, if > the NFS share never comes back you have to kill the application. > The solution is soft mount, but there are some caveats about silent > corruption of the data in that case. A random link about this: > https://www.centos.org/forums/viewtopic.php?t=8787 > Best regards, > Guillermo
If somebody's NAS box (or NFS client) is locking up after what can't be more than 1GB (if that) transfer, something is very wrong and you want to fix that. It's also possible that it's simply running slowly and you need to be more patient, but if it's on a reasonably fast LAN, modern-day NFS should be able to deal with it. You do *NOT* want to use soft mounts for this. I repeat: you do ***NOT*** want to use a soft mount here! Yes, that probably will result in your darktable not hanging (unless it's not hanging but is simply slow), but that's only because it will give up and return an error. Does darktable handle the error reasonably, or does it barf, or crash, or just ignore it (and then you have corrupted images)? If you're lucky, unless darktable itself retries saving the files (which is unusual) you're just going to have to repeat the operation. More likely is that a hang (or apparent hang) will be replaced by data loss. I quite frankly have a very difficult time seeing any good use for soft mounts other than perhaps for non-critical read-only access. So if these photos were stored read-only, mounting soft would be reasonable. In the bad old days of NFS, before intr (and later, force umount -f and remount) came along, soft mounts were the only way to avoid a hard lockup if some random filesystem froze, but with intr available, there's no good reason to use soft mounts and risk data corruption (silent if apps aren't checking, otherwise not silent but only recoverable if the app is reasonable). Bottom line: if this is due to NFS lockup, the solution is not to exchange lockup for data loss. It's to fix the NFS lockup, which is likely due to misconfiguration somewhere. > On Thu, Jan 25, 2018 at 4:33 PM Michael Staats <michael.sta...@gmx.de> > wrote: > >> Hi >> >> darktable 2.4.0 (but also many older versions) >> xubuntu 16.04 >> >> I have the following issue: >> After importing I usually have a quick glance at each image and "reject" >> (r) the obvious candidates in darkroom. >> Then I switch to lighttable, view "rejected only", select all, and press >> delete. >> >> The more images selected, the higher the chance that darktable either >> hangs while deleting (and has to be killed), or crashes. Means: 3 >> usually works, 12 is critical, 40 is almost certainly a crash. Almost, >> since sometimes it works. >> >> Fortunately, all edits including the rejects are still there after a >> restart, so it's only a minor issue I ignored for quite some time now. >> >> Since this occurs for quite some versions now I thought I'd ask here. >> Anybody else having this issue or is this my setup or whatever? >> >> Note: My images are located on a NAS, mounted via nfs v3, but my home >> dir (i. e. including .config/darktable/*db) lives on a local SSD. I have >> disable "send files to trash when erasing images" in the prefs. >> >> Best regards, >> Michael -- Robert Krawitz <r...@alum.mit.edu> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
