Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fresh install /.dvc/updater.lock for all commands #2897

Closed
hjuhel-cdpq opened this issue Dec 5, 2019 · 9 comments · Fixed by #2918
Closed

Fresh install /.dvc/updater.lock for all commands #2897

hjuhel-cdpq opened this issue Dec 5, 2019 · 9 comments · Fixed by #2918
Labels
bug Did we break something?

Comments

@hjuhel-cdpq
Copy link

hjuhel-cdpq commented Dec 5, 2019

Setup informations

dvc --version
0.71.0

Installed with pip, on a Ubuntu 18.04 version

Issue

Hi,

I am m new to DVC. I have installed DVC on a fresh Ubuntu install. Every command (except init and get) I tried to run raised the following error :

ERROR: unexpected error - [Errno 1] Operation not permitted: '<path_to_repo>/.dvc/tmp/bb2d3250118bf7b0d1042b10868e8e14.lock' -> '<path_to_repo>/.dvc/updater.lock'

With <path_to_repo> being a path to a working Git repository.

The issue first occured when I was following the "Get Started" section of DVC :

dvc get https://github.com/iterative/dataset-registry/get-started/data.xml -o data/data.xml
dvc add data/data.xml

For now I have tried :

  • To remove the updater.loc, but the file does not exist
  • To remove the .dvc/tmp/*.lock .

The status is not working neither.

Can you help figuring out what I'm doing wrong please ?

@triage-new-issues triage-new-issues bot added the triage Needs to be triaged label Dec 5, 2019
@efiop
Copy link
Contributor

efiop commented Dec 5, 2019

Hi @hjuhel-cdpq !

Could you please install psutil using pip install psutil and then show us dvc version(note that it is not the same as dvc --version) output?

@efiop efiop added the awaiting response we are waiting for your reply, please respond! :) label Dec 5, 2019
@triage-new-issues triage-new-issues bot removed the triage Needs to be triaged label Dec 5, 2019
@hjuhel-cdpq
Copy link
Author

Hi @efiop

Thanks for your response

My bad, I did not noticed the differences between the two commands.

The output of the command is the following :

DVC version: 0.71.0
Python version: 3.6.9
Platform: Linux-4.15.0-72-generic-x86_64-with-Ubuntu-18.04-bionic
Binary: False
Package: pip
Filesystem type (cache directory): ('fuse.vmhgfs-fuse', 'vmhgfs-fuse')
Filesystem type (workspace): ('fuse.vmhgfs-fuse', 'vmhgfs-fuse')

@efiop
Copy link
Contributor

efiop commented Dec 5, 2019

@hjuhel-cdpq Got it. So looks like you are running on a FUSE fs, which doesn't have hardlink implemented. Related to #2831 . I suppose it is a virtual machien that you are running and that partition is coming from the host, right?

@hjuhel-cdpq
Copy link
Author

Yes you are right. The I'm using a directory mounted on my VM but hosted in the Windows Host.

@efiop
Copy link
Contributor

efiop commented Dec 5, 2019

@hjuhel-cdpq Could you try installing this dev version:

pip uninstall -y dvc
pip install git+https://github.com/efiop/dvc@2831

and then run dvc status please? The dev version is trying to use flock-based locks instead of hardlink-based locks, so if vmhgfs supports flock then everything should start working.

@hjuhel-cdpq
Copy link
Author

It's working ! Thanks a lot ! The "add" seems to be working too. Do you plan to permanently use flock locks ?

@efiop
Copy link
Contributor

efiop commented Dec 5, 2019

@hjuhel-cdpq We'll definitely bring back flock by default and either will automatically detect that it is not supported (so far it seems problematic, as it might just hang forever on some nfs versions) or will introduce a config option to use nfs locks. Or, there is one more idea, where we could make the lock dir configurable, so that we could place the locks somewhere outside of the repo. In any case, it is on our TODO list for this sprint, so the permanent solution is coming soon, stay tuned! 🙂 Thanks for the feedback!

@efiop
Copy link
Contributor

efiop commented Dec 5, 2019

@hjuhel-cdpq One more workaround would be to only use fuse mount as an external directory (see dvc cache dir command in our docs), while having the main repo on a normal FS (.e.g ~/ should probably be okay).

@hjuhel-cdpq
Copy link
Author

I have start reading about the cache dir in the docs. I am definitely going to try this too.
Thanks again forhaving be so helpfull.

@efiop efiop added bug Did we break something? and removed awaiting response we are waiting for your reply, please respond! :) labels Dec 8, 2019
efiop added a commit to efiop/dvc that referenced this issue Dec 13, 2019
As it turned out (see issue numbers down below), we can't really take
hardlinks for granted, so `flufl.lock` is not a panacea for all
filesystems. Considering that the vast majority of filesystems that our
users use support `zc.lockfile`(flock-based) and it has benefits like
more reliable mechanism, auto-delete when process exits, more sturdy
implementation, etc, it makes more sense to bring it back and use by
default again. For filesystems that don't support `flock()`, users will
be able to manually enable `flufl.lock` use through the config option.
It would be ideal if we could auto-detect that flock is not supported,
but in the real world, it turned out to be non-trivial, as it might hang
forever in a kernel context, which makes the implementation way too
complex for our purposes. So what we're doing instead is showing a
message before locking with `zc.lockfile` that, under normal
circumstances will disappear once the lock is taken or failed, otherwise
it will point users to the related documentation where they can learn
about how to opt-in for `flufl.lock`.

Fixes iterative#2831
Fixes iterative#2897
Related iterative#2860
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Did we break something?
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants