Does Snapshot size increase when renaming files

[Keven]

Hi,

Since I implemented snapshot on my freenas server, I have always been scared to rename a file because i'm not sure if it would double the disk space needed. After a quick search on google it look like it's too dumb as a question to appear on any thread... Does renaming a file increase the disk space of a (file+ snapshot) as if it was a new file that needed to have it's own new snapshot ex:

file1=1GB
snap2014.file1=1KB
snap2015.file1=1KB
snap2016.file1=1KB

= 1.000003GB
renaming file 1 to 1a in 2017

snap2017.file1=1GB
file1a=1GB
snap.file1a=1KB


=2.000001GB

or is it smart enough to just store the "name change" instead of storing a complete copy of that file?

 

[Chris Moore]

My experience was that it sees this as two different files, not the same file with a different name. As if you copied the file to a different name and then deleted the original file.

 

[fracai]

My experience has definitely been different. Renaming a file (mv) is a metadata change. That'll be minimal space taken in a new snapshot. Copying a file (cp) would indeed increase the snapshot size by the file size. A hardlink (ln) would essentially be metadata.

This should be very easy to test.

Code:

dd if=/dev/urandom of=/mnt/tank/file1 bs=1m count=1000
zfs snap tank@snap1
mv /mnt/tank/file1 /mnt/tank/file2
zfs snap tank@snap2
zfs diff tank@snap1 tank@snap2
zfs list -o space -rd1 -t snap tank

'dd' will take a bit to complete, indicating many blocks written.
'mv' will complete immediately, indicating the blocks haven't been rewritten or copied.
'zfs diff' will report 'R', indicating the file has been renamed and nothing removed (-) or added (+).
'zfs list' will report the second snapshot as taking up almost no space. Actually, both will be listed as almost no space because they share all the blocks needed for file1 and file2.

 

[Chris Moore]

My experience has definitely been different. Renaming a file (mv) is a metadata change. That'll be minimal space taken in a new snapshot. Copying a file (cp) would indeed increase the snapshot size by the file size. A hardlink (ln) would essentially be metadata.

This should be very easy to test.

Code:

dd if=/dev/urandom of=/mnt/tank/file1 bs=1m count=1000
zfs snap tank@snap1
mv /mnt/tank/file1 /mnt/tank/file2
zfs snap tank@snap2
zfs diff tank@snap1 tank@snap2
zfs list -o space -rd1 -t snap tank

'dd' will take a bit to complete, indicating many blocks written.
'mv' will complete immediately, indicating the blocks haven't been rewritten or copied.
'zfs diff' will report 'R', indicating the file has been renamed and nothing removed (-) or added (+).
'zfs list' will report the second snapshot as taking up almost no space. Actually, both will be listed as almost no space because they share all the blocks needed for file1 and file2.

Does this work the same if the file operations are done from a Windows computer via the network?

Sent from my SAMSUNG-SGH-I537 using Tapatalk

 

[fracai]

Does this work the same if the file operations are done from a Windows computer via the network?

I would think so. SMB supports a rename command. I know I've renamed files over SMB on my Mac and the rename has occurred faster than I would have expected if it was making a copy of the file. Keep in mind that if it was actually making a copy the whole file would have to be transferred over SMB to your machine and then copied back under the new name.

 

[Keven]

Ok thank you guys for the help