Re: Btrfs subvolume question

["Markus Moeller" <huaraz@moeller.plus.com>]

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_vA@mail.gmail.com...

On Thu, Feb 5, 2015 at 1:28 PM, Markus Moeller <huaraz@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html