Freenas Files Upload Then Goto Zero Bytes

• #ane

I accept a dataset on my FreeNAS box that is a mirror of my PC. I run rsync on the PC periodically to update files on FreeNAS. I have a periodic snapshot task set to run every 12 hours on that dataset. My idea was that the periodic snapshot job would have care of versioning the changes to the dataset. As I posted in another thread, the FreeNAS GUI of the periodic snapshots is not showing anything for the "used" column on snapshots that should testify over 100 MB worth of changes.

Although I suspect that the issue is with the GUI and not the actual snapshots, I don't have a manner to verify that right now. Can anybody offer whatever assistance on how I tin can check if the snapshots are malfunctioning? I don't want to find out one day that I have uploaded and replaced a file with a corrupted version only to find out that the snapshots I thought I was making aren't working.

Cheers.

Last edited: Dec 25, 2015

• #2

More detail:

Using FreeNAS-9.3-STABLE-201512121950

Periodic snapshot task is set to run on pool/foo from 0:00 to 23:59 every 12 hours Sun - Sat. The snapshot task runs as expected and generates an entry in snapshots GUI.

If I run rsync on my PC and it updates files on puddle/foo, I would then expect that the snapshot from the last time I ran rsync would abound in size to match the changes in the newly uploaded files. This isn't happening, at least non in the GUI. If I become dorsum to the snapshot that was generated after the last sync, it still shows "0" in the used column. I'yard pretty sure this is a GUI outcome considering if I browse pool/foo from Windows the "Previous versions" correctly shows a version from the last time I ran rsync.

I suppose the worst case scenario would be that I have to manually notice every corrupted file and manually utilise Windows to restore each one, but that kind of defeats the purpose of having ZFS snapshots.

Even the GUI tips y'all off that it's lying. Cheque out the "Refer" column where you see the size of the dataset change from 381.seven GB to 381.9 GB. That'southward 200 MB of changes (it's files that are growing in size), but the snapshot size is still 0. I don't empathize. Information technology's almost similar the snapshot job is file-based instead of sector-based and it doesn't recognize that a file with the aforementioned proper name has changed.

Last edited: Dec 25, 2015

• #3

I'd open a problems (and postal service the # or link here and in the problems reporting department).

• #five

OK. I think I'one thousand virtually to feel like an idiot, merely hither goes: It occurs to me that well-nigh of the file changes are appends. With two versions of the same file, the kickoff x bytes of the latest version would be the same as the previous version. Theoretically that would mean each snapshot of this file would in fact be nada bytes considering you can reproduce the previous versions by truncating the electric current version - no data needed. I knew that already.

What I had assumed was that ZFS snapshots were sector-based. The probability of the end of a file landing exactly on a sector boundary is 1/ n , where n is the sector size (4096 in my case), which is usually a very small probability (<0.0002 in my instance). That would mean that even if data were only appended to a file, you would expect that the last sector of the file had inverse near every time data were appended. That would cause the snapshot to occupy at least due north bytes. What'south going to make me feel similar an idiot is if ZFS is smarter than being strictly sector-based (and bullheaded to the bytes in that sector), and "knows" that the only change to the file is purely appended information ... fifty-fifty though that appended information changes a sector that it had seen before.

Does that brand any sense? If that's the case it's really crawly on the one hand because I tin basically have infinite versions that occupy zero space (other than overhead), and when I do come across a positive number for the "Used" column I'll know some kind of corruption has taken identify in the file on my PC. On the other paw information technology'south kind of inconvenient considering I have no piece of cake way to place which snapshots actually contain a alter without manually looking through them to find the appointment and time when the size of the referred information changes.

Last edited: December 25, 2015

• #fifteen

Information technology seems as though you're suggesting, and perhaps FreeBSD and FreeNAS intend, that the "used" nomenclature isn't intended to describe the number of bytes that differ between a snapshot and the filesystem from which it originated. Instead, it seems, that "used" is intended to hateful "unique bytes found merely in this snapshot." If so, that would be a bizarre metric as I can't think of how it would be useful in the real world.

I understand the used value as the space used past the snapshots to retain the land of the data information technology refers to. If you just add together data but don't delete annihilation then the snapshot just demand to go on track of some metadata. If you delete (or change) some data the snapshot needs to continue the deleted data the used value is the small metadata tracking + the infinite used by the data.

gilesplis1938.blogspot.com

Source: https://www.truenas.com/community/threads/help-verifying-periodic-snapshots.40152/

Share this post