Hey guys, first post here. i think ill be posting more as i explore my nas drive a bit more...
so iv been dumping files onto my nas drive non stop for the last 24hrs. transfer speeds are good. averaging 20-50mb/s from pc to nas while transferring mainly 5g+ files.
now. when i first dumped some files on it they went on fine. but when i wanted to move (cut/paste) a folder from one location to another on the same disk (no raid) it basically takes the same amount of time to move it as it would to copy/paste.
iv tested this on the web browser and through windows and its the same result. its a bit annoying and im hoping there is a simple fix for this. we have a synology nas drive at work and it works fine.
If you are moving within the same shared folder (say from one subfolder to another) it does a file move.
However, if you are moving between shared folders it does a copy. That is because each shared folder set up as a btrfs subvolume. The benefit of that arrangement is that you get independent snapshots for each shared folder. The disadvantage is of course the inability to move files.
One of the benefits of BTRFS is Copy-On-Write. I am not sure I have figured out how to leverage that. I was expecting that copying files would have be instantaneous, but instead I am seeing real file copying.
Here's an example that might help. (Also I am using the word "link" very loosely. These aren't normal linux hard/soft links).
Say I create a snapshot right now. That doesn't take any more disk space, because the file system creates links in the snapshot for all the subfolders and files in the share. There is only one copy of the actual files.
Half an hour from now I delete a file. What happens is that the file is moved into the snapshot (the file replaces the old link). The total space doesn't change, because the file was moved into the snapshot and not actually deleted.
An hour from now, I copy a new file to the share from my PC. BTFRS writes it to the main share, but does not create a link in the file.
Two hours from now I move a file from one folder in the share to another folder in the same share. The move is instantaneous, and BTRFS leaves the original links in the snapshot alone.
Three hours from now I edit a file in the share, and save it back to the same filename. BTRFS moves the original file into the snapshot, and writes the new file into the folder.
Four hours from now I move a folder from a different share into this share. BTRFS can't do a normal move. Why? Because the snapshot feature requires each share be set up as a BTRFS subvolume - you can think of that as being a different hard drive, or a different disk partition. Moves always become copies when moving to a different disk, and BTRFS subvolumes need to do that also. The folder is copied into the this share, but no links are created in the snapshot. The folder is also copied into the snapshot of the original share.
The result is that the snapshot maintains the differences between the current share contents and the contents at the time the snapshot was taken. This is leveraging copy-on-write - as files are written, they are copied to the snapshot.
Copy-on-Write is more flexible than journaling (which can't do the snapshot trick). But (apart from snapshots) there is nothing you have to do to leverage it. There is a performance impact to using it (in particular the need to copy sometimes when ext would have allowed a move).
