jclulow
commented
10 months ago If you want to preserve the contents, I think the basic pattern is:
- rename the existing directory; e.g.,
debugtodebug-old - ensure the real dataset is mounted, which will recreate the mountpoint directory on its own
- copy the files from
debug-oldtodebug, unlinking them as you go - remove the
debug-olddirectory once empty
NB: You cannot merely rename the files from debug-old to debug, unfortunately, because it is a cross-file system operation, and links cannot span file systems.
bnaecker
While working on some zone bundle improvements, I noticed that the debug datasets we create on the U.2s, which are used for cores and archived logs, are not actually mounted.
When the sled-agent starts up, we create a hierarchy of datasets on each U.2. These are structured like
<pool_name>/crypt, with child datasets underneath, such aszoneordebug. The<pool_name>/crypt/zonedatasets have further children under them, which are the root filesystems for each zone we launch in the control plane. As an example, from the current dogfood rack, we have:The
debugdataset is intended for cores, crash dumps, and also archived logs from the zones. Here is where it's supposed to be mounted:And there are indeed directories there:
However, if we look at the dataset that those directories actually belong to, we see this:
I.e., they are in the base
cryptdataset, not the expected one atcrypt/debug. And in fact, those directories do not show up in/etc/mnttab:And just to double-check, they are in fact not mounted:
Also, we appear to still be archiving logs into those debug directories, in the
cryptdataset:And we can see there are many files in the archive directory implied by that last Propolis zone name:
There are also core files in those locations:
To summarize:
So, it appears that those directories have been created at some prior point, which prevents ZFS from automounting the
.../crypt/debugdataset over them. It's not totally clear to me what the right path forward here is. Deleting those directories is needed for them to be automounted, but we also don't want to necessarily blow away any of the existing debug data.