<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 27, 2020 at 11:53 PM Chuck Musser <<a href="mailto:cmusser@sonic.net">cmusser@sonic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've run Dfly for several years now, but never paused to understand <br>
HAMMER2 (or for that matter, it's predecessor) very deeply. I've used <br>
undo(1) a few times, but haven't dug into concepts like clustering or <br>
even what exactly PFSes are used for. I have a feeling I'm missing out <br>
on interesting things. So I'm finally getting around to asking a <br>
scattershot bunch of questions. I'm using my simple one-disk setup as a <br>
starting point. Its df -h output is below:<br>
<br>
Filesystem Size Used Avail Capacity Mounted on<br>
serno/5QE57G6D.s1d 193G 1054M 192G 1% /<br>
devfs 1024B 1024B 0B 100% /dev<br>
/dev/serno/5QE57G6D.s1a 1022M 187M 753M 20% /boot<br>
/dev/serno/5QE57G6D.s1e@DATA 18.5G 123M 18.4G 1% /build<br>
/build/usr.obj 18.5G 123M 18.4G 1% /usr/obj<br>
/build/var.crash 18.5G 123M 18.4G 1% /var/crash<br>
/build/var.cache 18.5G 123M 18.4G 1% /var/cache<br>
/build/var.spool 18.5G 123M 18.4G 1% /var/spool<br>
/build/var.log 18.5G 123M 18.4G 1% /var/log<br>
/build/var.tmp 18.5G 123M 18.4G 1% /var/tmp<br>
tmpfs 935M 0B 935M 0% /tmp<br>
procfs 4096B 4096B 0B 100% /proc<br>
tmpfs 935M 0B 935M 0% /var/run/shm<br>
<br>
1. What are are the three entries that begin with "serno" and why is the <br>
root slice not prefixed with /dev/ like the other two? What does<br>
the nomenclature mean, specifically "5QE57G6D", "s1a" and "@DATA", for <br>
instance).<br></blockquote><div><br></div><div>All attached storage devices have a software-readable serial number and can be addressed by that serial number instead of by the raw device. This allows the raw device numbers to probe in random order or for the drive to be moved without having to make adjustments to /etc/fstab.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. Are the subdirectories under /build each their own PFS? What do those <br>
do and why are they there? As an administrator, when would I want to <br>
create my own PFSes? I saw someone's example of creating a set of jails <br>
on a dedicated PFS, but I don't understand the implications of doing <br>
that.<br></blockquote><div><br></div><div>The installer used to create a PFS for each major subdirectory but no longer does. Instead it just separates everything into three partitions. The 'a' partition is a small UFS filesystem containing /boot. We use UFS for /boot because its tiny and deletions immediately free up media space. The 'd' partition contains the root mount and anything that one would normally want to backup. For example, /home is on 'd'. The 'e' partition contains the /build mount and has all the stuff one would normally NOT want to backup, such as /var/crash, /usr/obj, /var/log, and so forth. I put /var/spool in there too but its debatable. Mostly I put /var/spool in there too because it might see significant activity and I wanted the root mount to be as unassuming as possible in crash situations.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3. What are null mounts? It seems like that's how you mount PFSes, at <br>
least judging by the output of the mount(1) command.<br></blockquote><div><br></div><div>A NULL mount mounts one directory that already exists in the filesystem onto another part of the filesystem. Both places reference the same directory. Also note that these NULL mounts are not PFSs. The installer no longer creates a separate PFS for each directory, it just creates three partitions ('a' for boot, 'd' for root, and 'e' for /build) and then uses NULL mounts to arrange the subdirectories that we want to physically be on /build.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4. What are clusters, in HAMMER2? Can I use them to create a big <br>
filesystem from storage on separate systems?<br></blockquote><div><br></div><div>Clusters are not implemented yet, but that's the idea.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
5. I think I recall hearing that the remote mirroring feature in HAMMER <br>
is not yet supported in HAMMER2. Is that status still accurate?<br></blockquote><div><br></div><div>This is correct. My recommendation for now is to just use a regular rsync or cpdup, and then use hammer2's snapshot feature to create a frozen snapshot of the backup. Ultimately mirroring will be built into the clustering. Not yet though.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
6. Although I have a feeling that RAID configuration is a lower level <br>
construct than HAMMER, what are the options? I did see that the <br>
natacontrol(8) is able to manage RAIDs, but If I happened to get my <br>
hands on NVMe storage, those might call for a different utility? There <br>
is a nvmectl, but it seems like it might be for a different purpose.<br>
<br>
Thanks,<br>
<br>
Chuck<br></blockquote><div><br></div><div>Honestly I don't recommend using NATA or natacontrol in any manner. The ATA code is extremely crufty, old, and just not reliable. Use AHCI mode (which attaches as /dev/da0, /dev/da1, etc...). The AHCI driver is fully supported and reliable. If the BIOS does not support an AHCI-based softraid then your best raid option with DragonFly is some sort of hardware raid solution that is underneath the filesystem.</div><div><br></div><div>It is possible to use DM (man dm) and the device mapper to do some things. Crypted volumes are typical. There is a mirroring feature in there too but I don't know how good it is because nobody uses it. There are no RAID features ported. We also have 'vinum' for RAID support but it is also very old and basically unsupported, though I have received reports that it still works.</div><div><br></div><div>Still, my recommendation is that for anything that fits on one drive no mirroring or RAID should be used. Make discrete backups to another drive on a regular schedule instead. RAIDs are not actually any more reliable than non-RAID on small systems in terms of machine uptime. For larger many-drive arrays HAMMER2 just isn't the right solution (not yet) and I would recommend running ZFS on FreeBSD instead. But for any single-drive solution (even a large one), HAMMER2 gives premium performance and has a number of extremely useful features built-in such as automatic de-duplication (when copying a large file or tree), and compression. I use HAMMER2 on a bunch of 4TB HDDs and SSDs myself and it works flawlessly.</div><div><br></div><div>-Matt</div><div><br></div></div></div>