Eugene M. Zheganin | 10 Nov 10:58 2015

zfs, mc, mcview and files opening


my midnight commander is terribly slow at vieweing files with mcview.
Opening of a file of approximately 10 megabytes takes about 30-40
seconds. This isn't related with the compression setting, %busy wait or
pool properties- I tested on various machines, it's fully reproducible.
This lag appears on files about 1.5 megs in size, and the lag time is
pretty constant.  From my observation, it's the following syscall that's

fstat(4,{ mode=p--------- ,inode=41,size=0,blksize=4096 }) = 0 (0x0)
(observed using `truss mcview maillog`)

If the file is viewed not by mcview (i.e. it is of a special type and
viewed by the special utility, or mcview is simply not used - for
example more opens same file without lag) - the file is opening fast as
always. When mcview is involved - lag appears. In the same time I've
never seen this lag on filesystems other than zfs. And the most
beautiful detail is that this lag is repeatable on multiple opens of
same file - though you can expect that it will be only first time that
would be that slow, it doesn't happen - same pause occurs on sequential

Who's issue is this ?
Can some workaround be used ?

freebsd-stable <at> mailing list
(Continue reading)

Kathryn Britton | 9 Nov 22:10 2015

Avaya Users List


I just wanted to drop you a quick note to see if you would be interested in a discussion about "Avaya Users
List" and the benefits it can bring your organization for your Marketing Initiatives like Email
Marketing, Tele Marketing, Direct Mailings etc.

Every contact will include: Company Name, Web Address, Contact Name, Verified Email, Job Title,  Complete
Mailing Address, Phone Number, FAX Number, Total  Employees, SIC Code, and Industry details.

We guarantee 100% on that list type that means every individual on that list will be as per your criteria for
sure, any irrelevant contact will be replaced at no cost.

Few Technology Specific Lists:-

(1)Symantec Enterprise Security Manager                                (15) Siemens Enterprise Communications Users
(2) SAP Security                                                       (16) Avaya Network Hardware Users
(3) RSA SecurID                                                        (17) BlueCat Networks Users
(4) Cisco IP Telephony (VoIP)                                          (18) Cisco Unified Wireless Networks Users
(5) Cisco Telephony Hardware                                           (19) Dell Switches Users
(6) Cisco Voice and Data Networks User                                 (20) Juniper Networks Users
(7) Cisco VPN Users                                                    (21) Web Developers
(8) Security users
(9) Virtualization Users
(10) VMware Cloud Users
(11) Juniper VPN Users
(12) Nortel Communications Server (CS) Users
(13) Nortel VoIP Users
(14) Dell Backup Users and more....

(Continue reading)

Twitter via freebsd-stable | 8 Nov 23:21 2015

Confirm your Twitter account, COLLETTE WALFORD


Confirm your email address to complete your Twitter account. It's easy - just click on the button below.

Click on the link below or copy and paste it into a browser:;t=1&amp;cn=ZW1haWxfY29uZmlybV9pbml0&amp;sig=cf308a1adeb336c2a718f0b6577225ae34ff2f29&amp;iid=8eec6d5ba7584724949b02764469fcf5&amp;uid=4144794677&amp;nid=244+308
freebsd-stable <at> mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at>"

Trond Endrestøl | 7 Nov 12:58 2015

Merging r286233 to stable/10?


Would someone please consider merging r286233 to stable/10?


| Vennlig hilsen,               | Best regards,                      |
| Trond Endrestøl,              | Trond Endrestøl,                   |
| IT-ansvarlig,                 | System administrator,              |
| Fagskolen Innlandet,          | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,       | Cellular...: +47 952 62 567,       |
| sentralbord 61 14 54 00.      | Switchboard: +47 61 14 54 00.      |
freebsd-stable <at> mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at>"

Twitter via freebsd-stable | 6 Nov 17:39 2015

Confirm your Twitter account, RICKON ZIEMSKI


Confirm your email address to complete your Twitter account. It's easy - just click on the button below.

Click on the link below or copy and paste it into a browser:;t=1&amp;cn=ZW1haWxfY29uZmlybV9pbml0&amp;sig=a3d2b7cb120a7163ef75b74fbd6acec0d530c57f&amp;iid=11a89e250b5e493e8a272eb67ec4a9d8&amp;uid=4128034383&amp;nid=244+308
freebsd-stable <at> mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at>"

Dustin Wenz | 5 Nov 22:51 2015

Re: Question about "pcpu" rctl

As far as I know, pcpu has never worked for limiting beyond a single core. I submitted a patch for
kern/kern_racct.c that should fix it:

Please update the bug if it does or doesn't resolve the issue. Maybe that will prompt a committer to apply it
to stable.

	- .Dustin

> Anyone can advise me please?
> Thanks!
>     From: John Dison via freebsd-stable <freebsd-stable at>
> To: "stable at" <stable at> 
> Sent: Tuesday, September 15, 2015 1:00 PM
> Subject: Question about "pcpu" rctl
> Hello and have a nice day!
> I try to limit cpu usage for multi-threaded process on a multi-core machine.
> I use the following command:
> # rctl -a user:myusernm:pcpu:deny=200/user
> And I expect (please correct me if I am wrong) that all processes running with uid=myusernm will consume
200% of CPU in total.
> But after that I see that multi-threaded process continues to consume all available cores on my machine.
> rctl command reports:# rctluser:myusernm:pcpu:deny=200
> What am I doing wrong?

(Continue reading)

Eugene M. Zheganin | 5 Nov 20:29 2015

unable to boot a healthy zfs pool: all block copies unavailable


Today one of my zfs pool disks dies, I was unable to change it on the
fly (video board was blocking it) so I powered off, changed disk (not in
root pool) and all of a sudden I realized that i cannot boot:

ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS of pool zroot
gptzfsboot: failed to mount default pool zroot

It was first reboot since October, 16th, when I installed recent -STABLE
and upgraded zpool. I was pretty confident that I've installed loaders,
but I tried to reinstall them - no luck. Then I built today's STABLE and
installed loaders from it - same issue. I've even tried to install less
recent loaders from a server nearby - same issue.

Two years ago I have encountered similar (if not identical) issue:
The main difference was it was i386. Now I have an amd64 machine. I even
updated it's BIOS, and I still cannot boot. Zpool is fine: I'm writing
this message from this exact machine, however, I had to boot it from
today -STABLE from an USB stick.

I've read about the zfsboottest utility and tried it on my unbootable
pool - after the bried info about it (traated as healthy) it said "OK".
I guess no errors were encountered.

So... what can I do to restore the ability to boot from my root pool ?

(Continue reading)

Anton Shterenlikht | 5 Nov 18:10 2015

ia64: pcpu.h: No such file or directory

On ia64 10.2-STABLE #17 r289997
I get a panic as soon as I start
poudriere bulk

I see in core.txt:

Reading symbols from /boot/kernel/nullfs.ko.symbols...done.
Loaded symbols for /boot/kernel/nullfs.ko.symbols
#0  doadump (textdump=18810336) at pcpu.h:85
85	pcpu.h: No such file or directory.
	in pcpu.h
(kgdb) #0  doadump (textdump=18810336) at pcpu.h:85

If I remember correctly poudriere loads nullfs.

freebsd-stable <at> mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at>"

Sean Kelly | 29 Oct 17:54 2015

ZFS, SSDs, and TRIM performance

Me again. I have a new issue and I’m not sure if it is hardware or software. I have nine servers running
10.2-RELEASE-p5 with Dell OEM’d Samsung XS1715 NVMe SSDs. They are paired up in a single mirrored zpool
on each server. They perform great most of the time. However, I have a problem when ZFS fires off TRIMs. Not
during vdev creation, but like if I delete a 20GB snapshot.

If I destroy a 20GB snapshot or delete large files, ZFS fires off tons of TRIMs to the disks. I can see the
kstat.zfs.misc.zio_trim.success and kstat.zfs.misc.zio_trim.bytes sysctls skyrocket. While this
is happening, any synchronous writes seem to block. For example, we’re running PostgreSQL which does
fsync()s all the time. While these TRIMs happen, Postgres just hangs on writes. This causes reads to block
due to lock contention as well.

If I change sync=disabled on my tank/pgsql dataset while this is happening, it unblocks for the most part.
But obviously this is not an ideal way to run PostgreSQL.

I’m working with my vendor to get some Intel SSDs to test, but any ideas if this could somehow be a software
issue? Or does the Samsung XS1715 just suck at TRIM and SYNC?

We’re thinking of just setting the vfs.zfs.trim.enabled=0 tunable for now since WAL segment turnover
actually causes TRIM operations a lot, but unfortunately this is a reboot. But disabling TRIM does seem to
fix the issue on other servers I’ve tested with the same hardware config.


Sean Kelly
smkelly <at>

freebsd-stable <at> mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at>"
(Continue reading)

Lev Serebryakov | 29 Oct 15:24 2015

10-STABLE buildworld fails at very early stage

I have this in /etc/src.conf (it is only one line here):


% cd /usr/src
% sudo svn up
Updating '.':
At revision 290139.
% sudo make buildworld
[one screen of output]
set -e; cd /usr/src/tools/build; make buildincludes; make installinclude
sh /usr/src/tools/ -C -o root -g wheel -m 444   libegacy.a
install: /usr/home/build/obj/legacy/usr/lib: No such file or directory
*** Error code 71

make[3]: stopped in /usr/src/tools/build
*** Error code 1
% uname -v
FreeBSD 10.2-PRERELEASE #7 r286065: Thu Jul 30 21:27:35 MSK 2015
root <at> :/usr/obj/usr/src/sys/BLOB


// Lev Serebryakov

Re: Stuck processes in unkillable (STOP) state, listen queue overflow

Good day everyone !
From my point of view it seems like you're experiencing the "downgraded" hardware performance which
causes you the problems you meet.
Try to switch for the "new-one" power supply at least.
Why I think so ? Because the bad power supplies are met much more often than the bad source code for FreeBSD. Of
course I can't tell you you're completely wrong.
Best regards, Dimitry.
>Среда, 28 октября 2015, 12:00 UTC от freebsd-stable-request <at>
>Send freebsd-stable mailing list submissions to
>freebsd-stable <at>
>To subscribe or unsubscribe via the World Wide Web, visit
>or, via email, send a message with subject or body 'help' to
>freebsd-stable-request <at>
>You can reach the person managing the list at
>freebsd-stable-owner <at>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of freebsd-stable digest..."
>Today's Topics:
>   1. Re: Stuck processes in unkillable (STOP) state, listen queue
>      overflow (Zara Kanaeva)
>   2. Re: Stuck processes in unkillable (STOP) state, listen queue
(Continue reading)