It seems systemd creates the subvolumes.
cat /run/systemd/generator/local-fs.target.requires/var-opt.mount
# Automatically generated by systemd-fstab-generator
[Unit]
SourcePath=/etc/fstab
Before=local-fs.target
[Mount]
What=/dev/disk/by-uuid/7a681ad4-5b82-4e78-9b20-1d719c89fe6f
Where=/var/opt
Type=btrfs
Options=subvol=var/opt
Markus
"Chris Murphy" wrote in message
news:cajcqctt1psrfeu7q0qspnkqzy9nadhxzzye5y3fyqgzqqkt...@mail.gmail.com...
On Thu, Feb 5, 2015 at 1:28 PM, Markus Moeller <hua...@moeller.plus.com>
wrote:
Thank you for looking at this. I did post the fstab in the original
post.
Yep! No aware for my observation skills on this thread...
Here it is again:
Hmm, it's using UUIDs for the Btrfs volumes rather than using the
VG/LV. If you use
# lvs
that'll show the LVM LV's. But Robert already got this figured out.
The only thing I intended was to separate /, /var, /opt, /usr and /boot
as
I was used to, to avoid for example /var/log filling up the root
filesystem
( but now this fails :-( )
/var/log is on system_13.2/root_lv along with a bunch of other things.
According to your first df though, this 5GB root_lv is far from full,
not even 1/2 full. So I don't have a good explanation.
Anyway, long term this layout has maintenance problems, I would start
over. Backing up, restoring, even updating will pose problematic.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
