View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007798||ardour||features||public||2019-08-26 19:43||2019-08-26 20:14|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Summary||0007798: Use clone/CoW copies whenever possible|
|Description||I'm using Btrfs as the base of my Linux systems, a cool thing is that one can create "shallow" file copies there, by simply telling the filesystem "I want to copy this file here" instead of reading and writing the file example: `cp --reflink`. This saves disk space, as actual data is going to only be written when differences between the two files are starting to appear.|
I use a lot of snapshots in my Ardour sessions to have backup of my old versions and a way to check how the project evolved over time. This has saved me a couple of times.
However creating the snapshots fro big projects can take around 20- seconds or even longer, while Ardour is completely unresponsive (but the audio still plays).
I've learned that all MIDI regions are being copied for each snapshot - since creating CoW file copies is much faster than regular ones - this process would benefit a lot from using CoW duplication on filesystems like Btrfs and ZFS that support it
|Tags||No tags attached.|
Ardour load/saves MIDI files (not copies them). e.g. the file could be changed before saving the snapshot. Adding logic to detect when a file can be referenced as CoW is likely complex.
We try to avoid non-portable system specifics. There is very little OS specific code in Ardour, and we try to further reduce it.
Ardour does not directly interact that low level with the system. Besides, copy means reading and writing content. There is no system call (which is why it's slow).
Detecting file-systems and changing behavior depending on FS would have to bring significant benefits before we'd consider special casing it.
I also doubt that there is a significant benefit for the case at hand. MIDI files are perhaps 4kB on average. How large is a ZFS inode? minimum block-size?
||I understand, yes that's clearly out of the question then - solely based on the OS-specific code that'd be required and internal "which file was touched" logic.|