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
FilesystemSizeUsed Avail Capacity Mounted on
zroot/ROOT/default 67G4.2G 63G 6%/
zroot/usr/obj/usr 72G8.6G 63G12%/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).
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
