Shell Compare UFS and ZFS directories with mtree

tuaris

tuaris

I wanted to compare two directories across two different filesystems using the guide under https://forums.freebsd.org/threads/small-guide-on-using-mtree.61113. One is located on USF and the other is on ZFS. When I run mtree according the guide, I receive something like

Code: 
usr/lib/libnv.so:
        flags ("none" is not "uarch")
usr/lib/libc++.so:
        flags ("none" is not "uarch")
usr/lib/libufs.a:
        flags ("none" is not "uarch")
usr/lib/libtinfo_p.a:
        flags ("none" is not "uarch")
usr/lib/libavl.a:
        flags ("none" is not "uarch")
usr/lib/libdevinfo.so:
        flags ("none" is not "uarch")
usr/lib/pam_ssh.so:
        flags ("none" is not "uarch")
usr/lib/libprocstat_p.a:
        flags ("none" is not "uarch")
usr/lib/lib80211.so:
        flags ("none" is not "uarch")
usr/lib/libosmcomp.so.3:
        flags ("none" is not "uarch")
usr/lib/libc++.a:
        flags ("none" is not "uarch")
usr/lib/libncurses.a:
        flags ("none" is not "uarch")
usr/lib/libopie_p.a:
        flags ("none" is not "uarch")
usr/lib/snmp_hast.so.6:
        flags ("none" is not "uarch")
usr/lib/libbz2_p.a:
        flags ("none" is not "uarch")
usr/lib/libprocstat.so:
        flags ("none" is not "uarch")
usr/lib/libcam_p.a:
        flags ("none" is not "uarch")
usr/lib/libdpv.so.1:
        flags ("none" is not "uarch")
usr/lib/libgpio.so.0:
        flags ("none" is not "uarch")
usr/lib/libtermlib.a:
        flags ("none" is not "uarch")
usr/lib/libprivateheimipcc.so.11:
        flags ("none" is not "uarch")
usr/lib/snmp_hostres.so.6:
        flags ("none" is not "uarch")
usr/lib/pam_krb5.so.6:
        flags ("none" is not "uarch")

If I'm right: flags ("none" is not "uarch") is a difference in the metadata between zfs and ufs. If that's true, is it possible to have mtree ignore that specific flag?
 
It's sort of metadata, but also sort of not.

Read about FreeBSD file flags. Honestly, I don't know where a good centralized introduction to them is ... maybe some section in the handbook? Personally, I always look at the documentation for chflags (it exists both as a command chflags(1) and as a system call chflags(2)). FreeBSD flags are sort of the same concept as Linux file attributes. Both are information about a file that is kept in file system metadata. Not all file systems implement all flags, but both UFS and ZFS do (at least all the common ones).

In this particular case, you just tripped over a particular difference between UFS and ZFS. The "uarch" files (meaning user-level archive) means something like: this file needs to be archived (or backed up, sort of the same thing). I could also mean that this file has been archived (or doesn't need to be backed up) I vaguely remember that one of the two file systems automatically sets (or clears) that flags when it is created or modified, and then backup/archive tools do the right thing when backing it up. So that flag exists in both file systems, and kinda sorta means the same, but it handled differently. So you can fundamentally ignore differences between the two file systems. Matter-of-fact, most people ignore that flag completely anyway, because few people actually do backups (sadly). And real-world backup systems use more sophisticated methods to control what files get backed up than one flag anyway.

Your second question: How to teach mtree to ignore the uarch flag? No idea. Read the man page or other documentation for mtree.

Historical remark: About 20 years ago, I started working on a new cluster file system, at the time called "StorageTank". It was intended to be the ultimate file system, not necessarily from a performance viewpoint, but from a total system integration viewpoint. The idea was that all the files in an enterprise would be stored in a single file system (similar to what Coda and AFS proposed for academic environments), distributed over all computers in an enterprise, and accessible uniformly from everywhere. Ultimately, the product failed in the marketplace, but that's a different story. But one of the half dozen reasons our group started working on it: a few people in the group had earlier created a backup system (which even today is considered the best in the industry), and they were upset that different file systems implemented metadata (such as "archive" flags, mtime, atime, ...) inconsistently or wrong. So they set out to create a file system that (a) does this correctly, and (b) is so good that it can replace all other file systems. Then backup doesn't need workarounds any more. Alas, it all failed.
 
You must log in or register to reply here.
Back
Top