Re: ZFS (in virtual machine): $HOME being a dataset causes xauth to timeout- access delays?
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? > ... - parv ___ 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"
ZFS (in virtual machine): $HOME being a dataset causes xauth to timeout- access delays?
Hi there, 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? - parv Before making $HOME (/aux/home/parv) a dataset ... aux0 mounted at /aux aux0/home at /aux/home Conversion of $HOME to a dataset .. % zfs create aux0/home/parv2 % mv /aux/home/parv/* /aux/home/parv2/ % mv /aux/home/parv/.* /aux/home/parv2/ % rm -rf /aux/home/parv % zfs rename aux0/home/parv2 aux0/home/parv ___ 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"
ACPI poweroff is not working on 13.0
Sorry, subject is too loud, but... My MB is ASUS M5A97R2.0. On FreeBSD v10, 11 and 12 ACPI poweroff (shutdown -p, halt -p, short click on power button) works as expected. After upgrade to 13.0 it does not power the system off anymore. The process comes to "re0: link state changed to DOWN" as usuall (terminating daemons, syncing FS, spinning down disks, disconnecting and shutting down devices), but then "re0: link state changed to UP" appears in 2 seconds and the system stays powered forever. With verbose kernel logging I see also up to 30 lines like "hdac0: wake_prep disabled wake for \_SB_.PCI0.SBAZ (S5)" after "re0: ... UP". Seems, instead of final power off the system tries to wake up. Does anyone see this behavior? How can I debug this? Some ACPI quirks? Thanks! A. ___ 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"
Re: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?
On Thu, Apr 01, 2021 at 11:20:44AM +0300, Lev Serebryakov wrote: | On 01.04.2021 2:39, Doug Ambrisko wrote: | | > | > I can only state that I use it only occasionally, and that when I do. I | > | > have had no problems with it. I'm glad that it's there when I need it. | > | | > | Thanks for the reply. Can you comment on your use cases - in | > | particular, did you use mirror, stripe, or raid5? If the first two | > | then gmirror, gconcat, gstripe, and/or graid are suitable | > | replacements. | > | | > | I'm not looking to deprecate it just because it's old, but because of | > | a mismatch between user and developer expectations about its | > | stability. | > | > It would be nice if graid got full support for RAID5 alteast I'm not sure | > how much the others are used for that are not fully supported (RAID4, | > RAID5, RAID5E, RAID5EE, RAID5R, RAID6, RAIDMDF) according to the man | > page. I started to hack in RAID5 full support and try to avoid writes | > if members didn't change. This limits our VROC support. | My experience, as co-author and maintainer of `sysutil/graid5`, | shows, that it is very non-trivial task. It contains many subtle | problems. | | `graid5` still has some undiscovered problems, and I don't think it | worth fixing in 2021, when we have ZFS for many years. The only advantage I see of graid supporting raid5 would be better support for VROC and people like RAID5. I don't like RAID5 for SSD's since it adds to write amplification issues but people like it. RAID5 had terrible write performance in Linux with concurrent I/O. I wanted to see if FreeBSD could do better. Intel seems to be pushing VMD since we recently had a FreeBSD user need newer VMD support since they couldn't turn it off in the BIOS. VMware doesn't support VROC. We support it a bit in that VMD allows graid to access the drives and deals with the Intel meta data. It doesn't read the info. from the EFI runtime. So in RAID 0, 1 and 10 should work. It would be nice if someone could install FreeBSD on working Linux config. No-one has asked for it so it doesn't seem very important. Thanks, Doug A. ___ 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"
Re: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?
On 01.04.2021 2:39, Doug Ambrisko wrote: | > I can only state that I use it only occasionally, and that when I do. I | > have had no problems with it. I'm glad that it's there when I need it. | | Thanks for the reply. Can you comment on your use cases - in | particular, did you use mirror, stripe, or raid5? If the first two | then gmirror, gconcat, gstripe, and/or graid are suitable | replacements. | | I'm not looking to deprecate it just because it's old, but because of | a mismatch between user and developer expectations about its | stability. It would be nice if graid got full support for RAID5 alteast I'm not sure how much the others are used for that are not fully supported (RAID4, RAID5, RAID5E, RAID5EE, RAID5R, RAID6, RAIDMDF) according to the man page. I started to hack in RAID5 full support and try to avoid writes if members didn't change. This limits our VROC support. My experience, as co-author and maintainer of `sysutil/graid5`, shows, that it is very non-trivial task. It contains many subtle problems. `graid5` still has some undiscovered problems, and I don't think it worth fixing in 2021, when we have ZFS for many years. -- // Lev Serebryakov ___ 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"
