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

[Feature request] support for btrfs' CoW (copy on write) feature #684

Open
zetok opened this issue Mar 3, 2017 · 4 comments
Open

[Feature request] support for btrfs' CoW (copy on write) feature #684

zetok opened this issue Mar 3, 2017 · 4 comments
Labels
Milestone

Comments

@zetok
Copy link

zetok commented Mar 3, 2017

When copying large amount of data on the same fs, data gets unnecessarily duplicated, and copying takes a lot of time. With support for CoW, copy can be made almost instantaneously without data being unnecessarily duplicated.

Use case: working on some large set of data that could get irreversibly damaged if something goes wrong (PEBKAC). In order to prevent destroying original data, one would work on the copy. Copying the data with spacefm takes a lot of time and disk space. With support for CoW amount of time and used disk space could be significantly reduced.

As a workaround I spawn terminal and do cp --reflink manually.

cp(1):

$ fallocate -l 20G file
$ time cp --reflink file{,2}

real	0m0.002s
user	0m0.000s
sys	0m0.001s

spacefm:
spectacle sc7534

@IgnorantGuru IgnorantGuru added this to the limbo milestone Jan 23, 2018
@IgnorantGuru
Copy link
Owner

I will leave this open as a request, as I don't know much about it. Perhaps @OmegaPhil has input.

Also know that custom commands can be added to SpaceFM's menus for additional functionality like this. If the copy method produces a progress output, this can be integrated into the task manager percentage complete, etc. Iow this may be implemented as a (bash) SpaceFM plugin.

@OmegaPhil
Copy link
Contributor

OmegaPhil commented Jan 23, 2018

For filesystems that support cow, this is definitely a good idea, not sure if SpaceFM would want to get specific about the precise filesystem involved though?

@IgnorantGuru IgnorantGuru modified the milestones: limbo, far Jan 23, 2018
@IgnorantGuru
Copy link
Owner

SpaceFM already detects btrfs for other reasons, so implementing this might not be so difficult.

Main thing I'd like to hear input on (as not a btrfs user) is should this be default behavior and should it be optional? Would power users (eg many SpaceFM users) expect/want this?

What is the norm on other file managers, just for the record, and why?

SpaceFM generally mimics CLI tools, and cp doesn't use this feature to copy by default, it requires the --reflink option, so why should SpaceFM make it default? eg What if the user is expecting duplicate data on disk, eg for backup?

Should this feature be transparent, default, optional, or plugin?

Overall, how should this be integrated into the UI?

@IgnorantGuru
Copy link
Owner

Looks like this is already implemented in pull request #640.

@IgnorantGuru IgnorantGuru modified the milestones: far, 1.0.6 Feb 9, 2018
@IgnorantGuru IgnorantGuru modified the milestones: 1.0.6, alpha Mar 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants