3

With ZFS being described as more like a database than a filesystem, it seems reasonable to expect it would behave a lot more like a version management system as well, intelligently managing file modifications, moves and renames. The questions specifically ask about snapshots, however snapshots have a lot in common with clones and

  1. When a file is modified in ZFS after a snapshot, will the snapshot be the same size and only the differences, or the whole file?
  2. When a file is moved in ZFS after a snapshot, will the snapshot remain essentially zero size?
  3. When a file is renamed in ZFS after a snapshot, will the snapshot remain essentially zero size?
  4. When a file has a hardlinked copy of itself after a snapshot, will the snapshot remain essentially empty?

  5. There is suggestion that BTRFS is designed to do largely the same things as ZFS, would it then be expected to have the same behaviours in these conditions?

  6. When a Windows machine accesses the ZFS share remotely over SAMBA, will the same behaviour above hold true or does SAMBA a subset of the standard drive instructions i.e. a move becomes a copy+delete?

  7. Is it possible to answer the questions above generically or are the answers all implementation-specific?

As requested by a commenter the following is a test performed on the operations described:

System information:

  • CentOS 7 kernel 3.10.0
  • ZFS v0.6.5.9-1

.

                  `zpool list`           `zfs list`
      POOL        SIZE  ALLOC   FREE    USED   AVAIL  REFER

Create pool: zpool create -m /test/mnt FILE-TEST /test/1.img /test/2.img

      FILE-TEST   224M  80.5K    224M    73K    192M    19K

Snapshot: zfs snapshot FILE-TEST@1

      FILE-TEST   224M   122K    224M    73K    192M    19K
      FILE-TEST@1                          0       -    19K

Create file: echo ‘test’ > /test/mnt/test.txt

      FILE-TEST   224M   132K    224M    95K    192M    21K
      FILE-TEST@1                        17K       -    19K

Increase file size: `head -c 128K /test/mnt/test.txt

      FILE-TEST   224M   678K   223M    490K    192M    148K
      FILE-TEST@1                        17K       -    19K

Snapshot: zfs snapshot FILE-TEST@2

      FILE-TEST   224M   267K   224M    239K    192M    148K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                          0       -     48K

Edit file, change last 4 bytes.

      FILE-TEST   224M  1.07M   223M    386K    192M    148K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K

Snapshot: zfs snapshot FILE-TEST@3

      FILE-TEST   224M   548K   223M    388K    192M    148K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                          0       -    148K

Rename file mv test.txt test2.txt

      FILE-TEST   224M   552K   223M    404K    192M    150K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K

Snapshot: zfs snapshot FILE-TEST@4

      FILE-TEST   224M  1.06M   223M    645K    191M    150K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                          0       -    150K

New folder: mkdir /test/mnt/subdir

      FILE-TEST   224M   716K   223M    420K    192M    151K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K

Snapshot: zfs snapshot FILE-TEST@5

      FILE-TEST   224M   790K   223M    424K    192M    151K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K
      FILE-TEST@5                          0       -    151K

Move file: mv /test/mnt/test2.txt /test/mnt/subdir/

      FILE-TEST   224M   584K   223M    444K    192M    151K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K
      FILE-TEST@5                        10K       -    151K

Snapshot: zfs snapshot FILE-TEST@6

      FILE-TEST   224M   602K   223M    447K    192M    151K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K
      FILE-TEST@5                        10K       -    151K
      FILE-TEST@6                          0       -    151K

Create hard link file: cp -l /test/mnt/subdir/test2.txt /test/mnt/subdir/test3.txt

      FILE-TEST   224M   603K   223M    466K    192M    152K
      FILE-TEST@1                        17K       -     19K
      FILE-TEST@2                       138K       -    148K
      FILE-TEST@3                        10K       -    148K
      FILE-TEST@4                         9K       -    150K
      FILE-TEST@5                        10K       -    151K
      FILE-TEST@6                        12K       -    151K

Observations from the above:

  • SIZE and FREE are very constant and consistent with consumed space of file(s)
  • ALLOC is random
  • REFER on snapshots seems to equal the then-current REFER on the pool
  • On most operations, USED on the snapshots is around 10KB, save for the file change, in which USED is slightly larger than the whole changed file size.
  • USED on the pool grows in unequal jumps
  • REFER gradually grows around 1K per operation
  • Non-current snapshots remain unaltered in size
  • 1
    What's your research? Have you tried to answer 1-4,6 by experiment? If not then why not? – Kamil Maciorowski Dec 8 '17 at 11:29
  • 2
    @KamilMaciorowski you pose a fair question, and I should have, and potentially actually have done this research. The point however of a QA site like this is to make information publicly accessible. In addition to that, my experimentation represents a single datapoint that, if the answer to 7.) is that it is implementation specific, would be generally irrelevant. If you know the answers, you can make them publicly accessible and searchable here, while reaping the benefit of increasing score. It's a win for everyone. – J Collins Dec 8 '17 at 12:26
  • "have done this research. The point however of a QA site like this is to make information publicly accessible" -- Right, but you didn't make your research publicly accessible. :) My very first comment was "what's your research?". If I were you I would go with "in my Debian the answers to 1-4 are ..., but the real question is 7 which is ... and I cannot answer this by myself". – Kamil Maciorowski Dec 8 '17 at 12:45
  • @KamilMaciorowski, you now have the wealth of data I generated, it took some hours and I'm not sure of what I've learned..! Would you like to add the information you have? – J Collins Dec 8 '17 at 16:12
  • I have none. I don't use ZFS at all. I upvoted the question. – Kamil Maciorowski Dec 8 '17 at 16:24
3
  1. When a file is modified in ZFS after a snapshot, will the snapshot be the same size and only the differences, or the whole file?

The blocks that are different increase the size.

This means if a file consists of 100 blocks and you modify a single byte (assuming one byte is smaller than one block), one new block will be added (101 total) at the end, your old file will reference blocks 1 to 100 (can be accessed read-only from the snapshot) and your new/current file will reference blocks 1 to 37 and 39 to 101 (or any other combination depending on your actual modification operation).

As soon as you destroy the snapshot, block 38 will be marked as free and can be overwritten (as long as no other snapshots reference it).

  1. When a file is moved in ZFS after a snapshot, will the snapshot remain essentially zero size?

Inside the same file system yes, aside from metadata (references must be rearranged, for example).

Between file systems it is a full copy+delete operation, even if the file systems are on the same pool or descendants of each other.

  1. When a file is renamed in ZFS after a snapshot, will the snapshot remain essentially zero size?

Yes, aside from metadata (for example your new name must be recorded somewhere).

  1. When a file has a hardlinked copy of itself after a snapshot, will the snapshot remain essentially empty?

Could you be more specific here?

  1. There is suggestion that BTRFS is designed to do largely the same things as ZFS, would it then be expected to have the same behaviours in these conditions?

I would not assume that it does everything the same.

  1. When a Windows machine accesses the ZFS share remotely over SAMBA, will the same behaviour above hold true or does SAMBA a subset of the standard drive instructions i.e. a move becomes a copy+delete?

You have two possible implementations for Windows file sharing - either the CIFS server developed by Sun for Solaris and opensourced with OpenSolaris/illumos, or the Samba SMB implementation that is used in nearly all GNU/Linux distributions and BSD systems:

  • The Solaris version is better adapted to ZFS features (like setting share properties directly on the file systems, implementation of ZFS snapshots as Windows Previous Versions.
  • On the other hand, the Samba version is more cross-plattform and has some more advanced features like (partial) SMB3 support, IIRC.

I assume that in the second case you have pretty much the same as on other systems, although I did not test it.

  1. Is it possible to answer the questions above generically or are the answers all implementation-specific?

You can answer it specifically according to the code that is on the illumos/OpenZFS repo (Github repository) if you like to read C code, or you can answer it generally according to the man pages and documentation. For example, the REFER, USED, etc. properties are explained there in detail. Most interesting manpages are man zpool (hardware, disk layouts, pool properties), man zfs (file system properties, snapshots, clones), man chmod (Solaris/illumos only, file and share ACLs) and man zdb (debugging and analysis).

| improve this answer | |
  • Regarding 4.) and the hardlinked copy, if you have a snapshot of a file then make a copy of it using say cp -l ... to generate a file with the same inode as it, will the difference stored between the snapshot and current file system be essentially zero, or will it be the size of the new file. Perhaps another question is whether ZFS is fully aware of hardlinks, which when asked that way should be an obvious yes. – J Collins Dec 12 '17 at 15:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.