Re: [netbsd-users] Re: zvol performance expecations? zvol swap?
Also to note - zpools get really unhappy when allocation gets up above 80% - a set of pre-allocated thick-provisioned zvols on a fresh zpool set aside for this purpose is probably ok to take above that limit though, but you might want to workshop that ... On Thu, 18 Feb 2021, at 11:15, Malcolm Herbert wrote: > I typically use ZFS on Solaris or FreeBSD but would recommend using a > different zpool for swap if you can so you can have a different vdev > layout more suited to that load (ie, RAID1 rather than RAID5) and/or to > tweak other settings as desired independently of your data zpools > > Either way, definitely provision your swap zvols as thick volumes so > that you have all the space you might need pre-allocated and you won't > force the system to hunt for more at the point where it is already > under load. Regards, Malcolm -- Malcolm Herbert m...@mjch.net
Re: Daemonizing processes in NetBSD
On Wed, 17 Feb 2021, Bob Proulx wrote: Starting a new process that does not know how to detach from the controlling terminal is the point where you either need it to know how to call setsid(2) or you need something else installed on the system which knows how to call setsid(2). The BSDs (and also Linux) have long had a daemon(3) library function which does setsid(2) and the other stuff needed to become a well-behaved daemon. It shouldn't be too hard to make a call in your program, or to write a wrapper (or port FreeBSD's daemon(8)) for programs which can't be modified. -RVP
Re: [netbsd-users] Re: zvol performance expecations? zvol swap?
I typically use ZFS on Solaris or FreeBSD but would recommend using a different zpool for swap if you can so you can have a different vdev layout more suited to that load (ie, RAID1 rather than RAID5) and/or to tweak other settings as desired independently of your data zpools Either way, definitely provision your swap zvols as thick volumes so that you have all the space you might need pre-allocated and you won't force the system to hunt for more at the point where it is already under load. Regards, Malcolm -- Malcolm Herbert m...@mjch.net
Re: zvol performance expecations? zvol swap?
Sad Clouds writes: > On Wed, 17 Feb 2021 13:15:39 -0500 > Greg Troxel wrote: > >> >> Suppose I create a 16G zvol on a pool that is a disklabel partition on >> an SSD. I would expect read/write performance that is near the >> native SSD read/write speed. > > Why would you expect that? In other words, you're expecting that a > complex file system like ZFS would have near zero overheads, which is > not possible. When you take into considerations things like checksums, > compression, encryption, etc, then the overheads could be quite > significant. I have not enabled compression or encryption, and I forgot about checksums. However, the use case for zvol is having zfs being a logical volume manager, and it would seem reasonably feasible to get high efficiencies via allocation of large numbers of blocks at once. So 10-20% slower wouldn't surprise me. Have you used zvols? What was your experience? signature.asc Description: PGP signature
Re: zvol performance expecations? zvol swap?
On Wed, 17 Feb 2021 13:15:39 -0500 Greg Troxel wrote: > > Suppose I create a 16G zvol on a pool that is a disklabel partition on > an SSD. I would expect read/write performance that is near the > native SSD read/write speed. Why would you expect that? In other words, you're expecting that a complex file system like ZFS would have near zero overheads, which is not possible. When you take into considerations things like checksums, compression, encryption, etc, then the overheads could be quite significant.
Re: Daemonizing processes in NetBSD
W dniu 17.02.2021 o 21:56, Edgar Pettijohn pisze:
If you have perl available the following should do what you
need. Wouldn't be too difficult to write something similar
in C as well.
#!/usr/bin/env perl
use strict;
use warnings;
use POSIX qw//;
sub daemonize {
defined (my $pid = fork()) or die "Can't fork: $!";
exit if $pid;
defined (my $ppid = fork()) or die "Can't fork: $!";
exit if $ppid;
chdir "/" or die "Can't chdir '/': $!";
POSIX::setsid or die "Can't start new session: $!";
}
daemonize();
eval {
my @cmd = @ARGV;
exec @cmd;
};
warn $@ if $@;
exit;
Thank you all for suggestions. Available software is in pkgsrc to do
just this in sysutils/daemond and sysutils/daemonize but I won't use it
for the startup script.
I will be asking the upstream project to include proper behavior or
command line switch.
If you're not familiar with AdGuardHome I encourage you to test it from
wip/adguardhome. It is similar to pi-hole: provides a DNS level blocker
(and DHCP server if you require it, but it's optional) with statistics,
logs and auto blocklist update. At my home it manages to block ~20% of
DNS requests and at my parent's home it's more like ~35%. Since it is a
list-based blocker (though it has some unique features to test domains
with AdGuard systems if you wish to do so) it is prone to false
positives but that heavily depends on your usage pattern and blocklists
you enable.
Regards
--
Bartek Krawczyk
Re: Daemonizing processes in NetBSD
If you have perl available the following should do what you
need. Wouldn't be too difficult to write something similar
in C as well.
#!/usr/bin/env perl
use strict;
use warnings;
use POSIX qw//;
sub daemonize {
defined (my $pid = fork()) or die "Can't fork: $!";
exit if $pid;
defined (my $ppid = fork()) or die "Can't fork: $!";
exit if $ppid;
chdir "/" or die "Can't chdir '/': $!";
POSIX::setsid or die "Can't start new session: $!";
}
daemonize();
eval {
my @cmd = @ARGV;
exec @cmd;
};
warn $@ if $@;
exit;
Edgar
Re: Daemonizing processes in NetBSD
Bartek Krawczyk wrote: > Oh I should have been more clear from the start. This is for rc.d script for > wip/adguardhome. Probably during startup it doesn't really matter, I believe you are correct. During boot time all processes start from the init daemon and will not be attached to a controlling terminal. So the system upon a fresh reboot should be okay. > but when I tested it with "service adguardhome onestart" etc. it > sticks on the console. Yes. If the original boot time start is stopped and then a new process is started from your terminal then that new process would inherit your terminal as a controlling terminal unless it detaches from it. Detaching is something all well behaved daemons do. I am not familiar with AdGuardHome at all. It can't be coded to be a well behaved daemon itself? That would solve the problem at the source of course. > I'm not sure installing additional software just for a single rc.d > script is a feasible solution. "&" works just fine for now and I > noticed it also in other script. If you reboot and it starts then it should be fine. Then just don't ever restart it! That would be fine. Starting a new process that does not know how to detach from the controlling terminal is the point where you either need it to know how to call setsid(2) or you need something else installed on the system which knows how to call setsid(2). Or it looks like you would need to install some additional software outside of base, along with your install of AdGuardHome software that is also outside of base. Bob
zvol performance expecations? zvol swap?
Suppose I create a 16G zvol on a pool that is a disklabel partition on an SSD. I would expect read/write performance that is near the native SSD read/write speed. I got >400 MB/s on read, and only about 80 MB/s write. I wrote again, guessing that the read was returning synthetic zeros and that the first write forced allocation, but got about the same: $ time dd if=/dev/zero of=/dev/zvol/rdsk/tank0/xen-netbsd-9-amd64 bs=32m 17179869184 bytes transferred in 212.227 secs (80950440 bytes/sec) reading back: $ dd if=/dev/zvol/rdsk/tank0/xen-netbsd-9-amd64 of=/dev/null bs=32m 17179869184 bytes transferred in 81.584 secs (210578902 bytes/sec) and reading the raw disk: $ time dd if=/dev/rwd0d of=/dev/null bs=32m count=512 17179869184 bytes transferred in 62.190 secs (276248097 bytes/sec) So zvol is a fair bit slower. It's not convenient to write the raw disk any more; it's an older SSD on an older machine and maybe my expectations of >80 is confused. Do people think zvol performance is close to native? I tried to swapctl -a the zvol, which failed. I have updated the zvol section in the HOWTO: https://wiki.netbsd.org/zfs/ signature.asc Description: PGP signature
