Date: Fri, 2 Apr 2021 07:51:57 -0700 From: John Kennedy <warlock@phouka.net> To: parv/freebsd <parv.0zero9+freebsd@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: ZFS (in virtual machine): $HOME being a dataset causes xauth to timeout- access delays? Message-ID: <YGcvjJWRaw3sYo1Z@phouka1.phouka.net> In-Reply-To: <CABObuOq=TO4Hon6%2BN%2BTfvk3QRiFPNb2UQWp5%2BXxH2mBJu5b5eA@mail.gmail.com> References: <CABObuOq2t2z1LNZpcPLgvrB85b81p0LXvM4-69iFfPXn_HvP=w@mail.gmail.com> <CABObuOq=TO4Hon6%2BN%2BTfvk3QRiFPNb2UQWp5%2BXxH2mBJu5b5eA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 01, 2021 at 07:18:56PM -1000, parv/freebsd wrote: > On Thu, Apr 1, 2021 at 3:38 PM parv/freebsd wrote: > > I am wondering if $SRC_BASE, $MAKEOBJDIRPREFIX, & $WRKDIRPREFIX being > ZFS datasets now would increase compile time. I will found that out in > few weeks (in case of buildworld & kernel) as earlier I had both $SRC_BASE & > $MAKEOBJDIRPREFIX as plain directories & took ~5--6 hours. > > I have FreeBSD 12-STABLE in VirtualBox 5.2.44 on Windows 10. All the "disks" > > are file-backed virtual disks. > > > > I noticed that after making $HOME a ZFS dataset, there were delays ... > > - generally in start of Xorg; > > - exhibited by xauth (after using "startx") error messages about timeout > > with authority files. > > > > After reverting back $HOME not being a dataset on its own as before, there > > are no delays in start of Xorg; nor are any timeout message from xauth as > > before. > > > > Has anybody else noticed that? I can't say that I've noticed any slowness. I normally don't use xauth unless I'm doing something exotic (like su to another user but want to have them able to use my X display), so probably not the best example. I've also been using zfs on FreeBSD in favor of any other filesystem since it was an option, so I'm probably probably totally worthless for speed comparison. That being said... I often feel like I'm rocking the 1986 X vibes because, while I like eye candy, that eye candy is coming with a lot of baggage. Gnome/KDE? Hah! I'm using ctwm. But if you've got said eye candy that wants to walk your file system tree and you've got a /home/$USER/.zfs/snapshot with lots of backups that is magnifying your tree, something might be doing a lot more work than the designer was originally expecting. As far as ZFS datasets go, I keep stock+ to keep my snapshot space low. I added a few things onto the stock ZFS partitioning: zfs create -o canmount=off zroot/usr/home/$USER zfs create zroot/usr/home/$USER/.cache zfs create zroot/usr/home/$USER/.mozilla zfs create zroot/usr/ports/distfiles zfs create -o canmount=off zroot/usr/obj zfs create zroot/usr/obj/usr zfs create zroot/poudriere So /home -> /usr/home is a dataset by default, /home/$USER isn't (I'm the only user, so I wasn't worried there), but because I like doing snapshot backups of things and I noticed that my snapshots were pretty damn big for what I was working on, I decided to strip out the browser droppings by making a dataset for .cache and .mozilla. Doesn't scale, but just me. To keep my zroot/ROOT/default and boot environments clean, I created the datasets for /usr/obj (kernel objects) because that is generally disposable (except when I was doing RPI work and that was precious gold since it took days to rebuild and I might want it to match a kernel I reverted to). I added oen for /usr/ports/distfiles to keep it from bloating out /usr/ports, which is also easily reconstructed (vs the tarballs, which sometimes go AWOL). In any case, for /usr/obj, some variation of this is what I was looking at: # df -h / /usr/obj/usr Filesystem Size Used Avail Capacity Mounted on zroot/ROOT/default 67G 4.2G 63G 6% / zroot/usr/obj/usr 72G 8.6G 63G 12% /usr/obj/usr I do not need 8G of stuff that I'll probably never use again snapshotted with my root filesystem that I may keep around for extended periods of time. On disk, each of the roots generally seems to use ~1.2G of space with what they have in common, but I wasn't going to get that with /usr/obj. Now, I've got a pretty beefy box, so my compiling pain points may not match yours but you can do things like tune the datasets. For example, if you're CPU bound and you have a lot of compression on /usr/obj, you may want to turn that off (while being able to leave it on for the root partition).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YGcvjJWRaw3sYo1Z>