Howto crashdump on ZFS-only system?

[Mjölnir]

Dear experts,

am I right that it is not possible to crashdump on a ZVOL (swap device) in FreeBSD 9.1?
If so, will it be available in the (near) future (9.3, 9.4...)?
If it is possible, then how?

My swap is larger than hw.physmem, in /etc/rc.conf

dumpdev="AUTO"

in /etc/sysctl.conf

kern.coredump=1

Manually setting $ sudo dumpon -v /dev/zvol/tank0/swap replies:

dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported

I have had crashes and I'd like to be able to examine.

Thanx in advance,
Torsten
--
=|o)

 

[Crivens]

Crashdumps require a swap partition that is a partition, not a virtual disk.
Because in case of a crash, the kernel is probably garbled really good, and to rely in that case that the data structures of anything are still valid (and ZFS requires lots of data in kernel space), is just asking for trouble.
The normal dump code takes a device and writes page for page onto it by nearly 'banging the metal', meaning with code being as low level as possible so the critical amount of things required for a correct operation is as small as possible. That shoud reduce the chances of the dump not going to swap space but maybe end up spread out all over your /home...

In case you need crash dumps, create a partition which is not covered by ZFS (even a USB stick should do it, I think) and declare it as dump device. I would bet on the feature you want to never arrive.

 

[Mjölnir]

Thanx for your quick answer!

Well, then the brave folks@Sun/Oracle and OpenIndiana must have strong confidence in the quality of their code, it's possible there.

A dedicated USB-Stick is an option, thanks for the hint. But... it's not built-in the system.

In my case -- Laptop+SSD -- this means I have to re-install and dedicate a partition of the size of my RAM of my SSD (4 of 128 G, 3%) solely as dump device, because it's not healthy for the SSD to swap there, whereas a ZVOL swap device is ok, because ZFS is COW it will not write to the same blocks over and over again.

Would a kernel patch to allow dumping to a ZVOL be (more or less) trivial?
--
=|o) "Stell Dir vor es geht und keiner kriegt's hin" - Wolfgang Neuss

 

[Crivens]

ZFS is part of Solaris, a lot more than it is in any other OS. That said, maybe they did change the crash dump code to be able to handle ZVols, or the ZVols there can deal with it, or they really trust it a lot more.

But what you want would require to make the ZVols support dumping (maybe dangerous, maybe a lot of work) or it needs you to repartition. The argument of using 3% does not count, IMHO, because you will then not need the ZVol which has the same size. Total free space should not change.

Using one of these small USB sticks, which only stick out some mm, would be my first try to get it going. They can be attached to your laptop all the time, but if in doubt you may secure them with some tape. And once you got the dump, you can debug the cause and remove the dump device again without much trouble.

And, even more simple, you might tell under what circumstances you had these crashes and someone might already have a soluton.

 

[Mjölnir]

The argument of using 3% does not count, IMHO, because you will then not need the ZVol which has the same size. Total free space should not change.

For a rotational HD, that's true. But like I said, I'm definitely not going to set up swap to a partition of an SSD, in contrast it's ok to use a ZVOL@SSD as swap space 'cause ZFS is copy-on-write. So, economical use of back-store resources comes back again w/ SSDs, back-store space isn't just "cheap" anymore. But, ok, I can make it a sparse volume, reserve only, say, 1 GB, and watch the zpool's and swap filling degree carefully. I'll think about that, but my 1st impression is that'd be asking for trouble. I use the laptop off-desk s/t, so I don't feel comfortable w/ a stick as dump device, it could break too easy etc. IMHO the dump device should be integral part of the system, available anytime. Easiest solution will be to buy a larger SSD and donate my current SSD to speed up my sister's old computer, making me feel like a boat owner.

Thanx so far for your answers.
--
=|o) "Pleasure boat: a p.b. is a hole in the water to throw your money in." -- Anonymous

 

[Crivens]

For a rotational HD, that's true. But like I said, I'm definitely not going to set up swap to a partition of an SSD, in contrast it's ok to use a ZVOL@SSD as swap space 'cause ZFS is copy-on-write.

The SSD is also doing wear leveling, and if your swap space is not used too much (which would mean that it slows the system down) then there is little to fear.

I use the laptop off-desk s/t, so I don't feel comfortable w/ a stick as dump device, it could break too easy etc.

I meant one of these.
"Sticks out" about 3mm, very hard to break anything with that I think.

IMHO the dump device should be integral part of the system, available anytime. Easiest solution will be to buy a larger SSD and donate my current SSD to speed up my sister's old computer, making me feel like a boat owner.

Whatever floats your boat

 

[kpa]

Would ZFS even be able to guarantee that a ZVOL of certain size is stored on consecutive blocks on the disk? Without such guarantee dumping on ZVOL would be impossible.

 

[Crivens]

Would ZFS even be able to guarantee that a ZVOL of certain size is stored on consecutive blocks on the disk? Without such guarantee dumping on ZVOL would be impossible.

Not impossible but certainly more risky. You'd need the block numbers in-core and then trust on that data not to be messed with. So in case you drop core because of some wild pointer in the kernel, which happens to scramble that data, you would end up with the dump all over the pool. And that is the second point, you'd need to reliably write to any config the pool may have (mirror, raidz, ...) and keep the checksums up to date. OR you would need to trust that all of the ZFS code + in-core data for the pool is still correct and use ZFS to write to the swap file. Seing how much memory is wired down when you run ZFS for some time makes me doubt that all that will be in order in case of a kernel crash. Kernel-level assert()s, maybe. But real traps?

 

[throAU]

Well, then the brave folks@Sun/Oracle and OpenIndiana must have strong confidence in the quality of their code, it's possible there.

Right here is where I point out that Oracle also maintain Java, which has one of the patchiest security records of any software out there at the moment, second only, perhaps to Flash.

Just because Oracle (or anyone else for that matter) do it, doesn't mean it is the right thing to do.