UFS ufs snapshot df inconsistency

Hi there everyone, new to the forums, working with FreeBSD since 6-STABLE, maybe.
I was recently trying and strip down a system for server user, snapshotting from time to time, and checking out how much space I've actually bitten out from the various docs, examples, tests, licenses, and whatnot.
With no apparent reason, suddenly the snaps were clogging my disk:
Code:
[cygnus-X1]# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ada0p2    9.7G    6.8G    2.1G    76%    /
devfs          1.0K    1.0K      0B   100%    /dev
/dev/ada0p4    213G    222M    196G     0%    /usr/home
[cygnus-X1]# rm /.snap/VIRGO-001
override r--r----- root/operator snapshot for /.snap/VIRGO-001? y
[cygnus-X1]# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ada0p2    9.7G    2.7G    6.2G    30%    /
devfs          1.0K    1.0K      0B   100%    /dev
/dev/ada0p4    213G    222M    196G     0%    /usr/home
That particular snap. VIRGO-001, I tried once to rsync remotely, but the network died and the transfer got stuck, so I thought it could be the culprit, and I was apparently right. Not to a subsequent check: (commands are in sequence)
Code:
[cygnus-X1]# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ada0p2    9.7G    2.7G    6.2G    30%    /
devfs          1.0K    1.0K      0B   100%    /dev
/dev/ada0p4    213G    222M    196G     0%    /usr/home
[cygnus-X1]# du -hd1 /
4.1G    /.snap
1.4M    /bin
 47M    /boot
5.0K    /dev
2.7M    /etc
 15M    /lib
264K    /libexec
4.0K    /media
4.0K    /net
4.0K    /proc
 13M    /rescue
1.4M    /root
6.8M    /sbin
 20K    /tmp
1.6G    /usr
279M    /var
4.0K    /mnt
6.0G    /
[cygnus-X1]# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ada0p2    9.7G    5.8G    3.1G    65%    /
devfs          1.0K    1.0K      0B   100%    /dev
/dev/ada0p4    213G    222M    196G     0%    /usr/home
[cygnus-X1]# locate sujournal
[cygnus-X1]# locate .sujournal
How can this be explained? Was it the du comd that 'triggered' the inconsistency?
Thanx for helping!
 
I'm sorry:
Code:
[cygnus-X1]# uname -a
FreeBSD cygnus-X1 13.1-RELEASE FreeBSD 13.1-RELEASE VIRGO amd64
[cygnus-X1]# config -x /boot/kernel/
config: '/boot/kernel/' is a directory
[cygnus-X1]# config -x /boot/kernel/kernel
options CONFIG_AUTOGENERATED
ident   VIRGO
machine amd64
cpu     HAMMER
makeoptions     NO_MODULES=yes
makeoptions     WITH_CTF=1
makeoptions     DEBUG=-g
options ATH_ENABLE_11N
options AH_AR5416_INTERRUPT_MITIGATION
options IICHID_SAMPLING
options HID_DEBUG
options EVDEV_SUPPORT
options USB_DEBUG
options IEEE80211_SUPPORT_MESH
options IEEE80211_DEBUG
options SC_PIXEL_MODE
options VESA
options PPS_SYNC
options COMPAT_LINUXKPI
options PCI_IOV
options PCI_HP
options IOMMU
options EARLY_AP_STARTUP
options SMP
options KDB_TRACE
options KDB
options RCTL
options RACCT_DEFAULT_TO_DISABLED
options RACCT
options INCLUDE_CONFIG_FILE
options DDB_CTF
options KDTRACE_HOOKS
options KDTRACE_FRAME
options CAPABILITIES
options CAPABILITY_MODE
options AUDIT
options HWPMC_HOOKS
options KBD_INSTALL_CDEV
options _KPOSIX_PRIORITY_SCHEDULING
options SYSVSEM
options SYSVMSG
options SYSVSHM
options STACK
options KTRACE
options SCSI_DELAY=5000
options COMPAT_FREEBSD12
options COMPAT_FREEBSD11
options COMPAT_FREEBSD10
options COMPAT_FREEBSD9
options COMPAT_FREEBSD7
options COMPAT_FREEBSD6
options COMPAT_FREEBSD5
options COMPAT_FREEBSD4
options COMPAT_FREEBSD32
options GEOM_LABEL
options TMPFS
options PSEUDOFS
options PROCFS
options CD9660
options MSDOSFS
options NFS_ROOT
options NFSLOCKD
options NFSCL
options MD_ROOT
options UFS_GJOURNAL
options UFS_DIRHASH
options SOFTUPDATES
options FFS
options IPSEC_SUPPORT
options INET
options PREEMPTION
options NUMA
options SCHED_ULE
options NEW_PCIB
options GEOM_PART_GPT
options GEOM_PART_MBR
options GEOM_PART_EBR
options GEOM_PART_BSD
device  isa
device  mem
device  io
device  uart_ns8250
device  cpufreq
device  acpi
device  pci
device  ahci
device  ata
device  scbus
device  ch
device  da
device  sa
device  cd
device  pass
device  ses
device  atkbdc
device  atkbd
device  psm
device  kbdmux
device  vga
device  splash
device  sc
device  vt
device  vt_vga
device  vt_efifb
device  vt_vbefb
device  agp
device  cbb
device  pccard
device  cardbus
device  puc
device  miibus
device  wlan
device  wlan_wep
device  wlan_ccmp
device  wlan_tkip
device  wlan_amrr
device  crypto
device  aesni
device  loop
device  padlock_rng
device  rdrand_rng
device  ether
device  vlan
device  tuntap
device  md
device  firmware
device  xz
device  bpf
device  usb
device  ukbd
device  umass
device  sound
device  mmc
device  mmcsd
device  sdhci
device  rtsx
device  evdev
device  uinput
device  hid
device  alc
device  ath
device  ath_pci
device  ath_hal
device  ath_rate_sample
device  uhci
device  ehci
device  snd_hda
[cygnus-X1]#
 
check if you have any other files in /.snap except VIRGO-002 and VIRGO-003. ls -lhoa /.snap

df should not count the snapshot file size unless it's mounted. Normally /.snap directory is used from dump(8) when perform a backup of the live system and after the backup of the snapshot is complete it's unmounted and removed from /.snap

Did you manually create the snapshot using mksnap_ffs(8) or using some other script like freebsd-snapshot (periodic-snapshot)
 
I haven't:

Code:
ls -lhoa /.snap/
total 4300360
drwxrwxr-x   2 root  operator  -         512B May 19 02:22 .
drwxr-xr-x  19 root  wheel     -         512B May 13 18:05 ..
-r--r-----   1 root  operator  snapshot   10G May 22 03:01 VIRGO-002
-r--r-----   1 root  operator  snapshot   10G May 22 02:34 VIRGO-003
I created the snaps manually:

Code:
[cygnus-X1]# mksnap_ffs /.snap/VIRGO-003

Also, the size is weird: it's obviously not the sum of the two snaps, and I can't guess what does it 'see' weighting 5.8GB
 
The size of ~4GB that you see in /.snap is the size of the modified data or deleted files after the snapshot was taken. The snapshot remap / track all changes of the file system and when it is created it doesn't take any disk space. It's size is equal of the size of the partition of where it was created (10GB) but it doesn't actually take this size from the disk.

For example if you have 1GB test file in your /root/ directory and create a snapshot the newly created snapshot will display a size of 10GB but it will actually take 0b
Then if you delete this 1GB file from the /root/ and check the size of the snapshot it will display again size of 10GB and will take 1GB of disk space which will hold the original deleted file inod number. So actually all data that is modified on the disk after the snapshot is created is kept as remapping inside the snapshot.

In your case if you delete snapshot 003 it will only free the space on the disk which was changed between May 22 03:01 and May 22 2:34 which may not be entire ~4GB modified files. To free the entire 4GB you need to delete all snapshots.
 
So actually all data that is modified on the disk after the snapshot is created is kept as remapping inside the snapshot.
I got this right? Any modifications made to the disk content after a snapshot impact on the snapshot's size?
So it is perfectly legit for the snapshot to 'grow', the more I strip down the system after taking it...
If it's so, I'll keep 'em as backups as long as I'm satisfied with the system in general, but I'll have to remove them before going prod, to actually enjoy the free disk space.
 
I would recommend reading the related sections of the handbook regarding UFS snapshots and such. You might find its descriptions very helpful. Also remember there are "apparent" occupied space and "actual" occupied space. (see: du(1))
 
Sounds like UFS snapshots are similar to ZFS snapshots. Basically Copy On Write. Take snapshot it references state of the filesystem "now".
Start deleting files from the filesystem, they disappear from the filesystem, but the blocks actually move to the snapshot. Filesystem shrinks, but snapshot grows as the blocks move from one to the other. This makes sense because the blocks are referenced by the snapshot and the active filesystem, remove from the active filesystem but are still referenced by the snapshot.
 
I got this right? Any modifications made to the disk content after a snapshot impact on the snapshot's size?
Yes the snapshot grow in size when you modify or delete data after it has been made. The snapshot is not a backup and should not be used as backup strategy. Snapshot is stored on the same block device. So if you lost the disk you will also lost your snapshot. For UFS backup use dump(8) and restore(8) it works great over ssh and remote server.
 
UFS does copy on first write of a block (first *after* a snapshot is created) but not later. ZFS does copy on write on every write (which implies also writing new indirect blocks, inode .. superblock). That is why I said "kind of"!
 
  • Like
Reactions: mer
Yes the snapshot grow in size when you modify or delete data after it has been made. The snapshot is not a backup and should not be used as backup strategy. Snapshot is stored on the same block device. So if you lost the disk you will also lost your snapshot. For UFS backup use dump(8) and restore(8) it works great over ssh and remote server.
Yeah correct: it was 'backup' as in 'fast recovery from messing everything up'. I'm meddling with the system to free up space, for the sake of it mainly, even in areas I don't deeply delve usually. So it's basically a 'yesterday wasn't broken, restore those files' startegy.
For actual backup, I in fact use a bunch of rsync-based scripts.

Thanx for the decisive knowledge.
 
Back
Top