On Tue, Nov 07, 2023 at 10:35:11AM -0800, Darrick J. Wong wrote: > The reason why I bolted on the SERVICE_MOUNTPOINT= environment variable > is to preserve procfs discoverability. The bash translation of these > systemd unit definitions for a scrub of /home is: > > mount /home /tmp/scrub --bind > SERVICE_MODE=1 SERVICE_MOUNTPOINT=/tmp/scrub xfs_scrub -b /home > > And the top listing for that will look like: > > PID USER PR NI %CPU %MEM TIME+ COMMAND > 11804 xfs_scru+ 20 19 10.3 0.1 1:26.94 xfs_scrub -b /home > > (I omitted a few columns to narrow the top output.) So if you make the pretty print mount point a new variable and pass that first this would become say: xfs_scrub -p /home -b /tmp/scrub ad should still be fine. OR am I missing something? > For everyone else following at home -- the reason for bind mounting the > actual mountpoint into a private mount tree at /tmp/scrub is (a) to > make it so that the scrub process can only see a ro version of a subset > of the filesystem tree; and (b) separate the mountpoint in the scrub > process so that the sysadmin typing "umount /home" will see it disappear > out of most process' mount trees without that affecting scrub. > > (I don't think xfs_scrub is going to go rogue and start reading users' > credit card numbers out of /home, but why give it an easy opportunity?) But scrub has by definition full access to the fs as it's scrubbing that. But I guess that access is in the kernel code, which we trust more than the user space code?
