Sean Thomas Caron
2010-Oct-20 15:46 UTC
Spurious reboot in 8.1-RELEASE when reading from ZFS pool with > 9 disks
Hi folks, I've been playing with ZFS in 8.1-RELEASE (amd64) on a Sun Fire X4500 with 16 GB RAM and in general it seems to work well when used as recommended. BUT... In spite of the suggestion of Sun and FreeBSD developers to the contrary, I have been trying to create some zraid pools of size greater than 9 disks and it seems to give some trouble. If I try to create a pool containing more than 9 [500 GB] disks, doesn't matter if it is zraid1 or zraid2, the system seems to reboot given any amount of sustained reads from the pool (haven't tested mirrored pools). Now, I am not sure of: - Whether the reboot in the zraid1 case is caused by exactly the same issue as the reboot in the zraid2 case - Whether this is an issue of total number of member disks, or total amount of disk space in the pool. All I have to work with at the moment is 500 GB drives. I am not doing any sysctl tuning; just running with the defaults or what the system automatically sizes. I tried playing around with tuning some sysctl parameters including setting arc_max to be very small and it didn't seem to help any; pools of greater than 9 disks in size are always unstable. Writes seem to work OK; I can, say, pull stuff from over the network and save it to the pool, or I can do something like, dd if=/dev/random of=/mybigpool/bigfile bs=1024 size=10M and it will write data all day pretty happily. But if I try to read back from the pool, for example, dd if=/mybigpool/bigfile of=/dev/null bs=1024 or even to just do something like, cp /mybigpool/bigfile /mybigpool/bigfile_2 the system reboots pretty much immediately. I never see anything on the console at all; it just reboots. Even if I build a new kernel with debugging options: options KDB options DDB the system still just reboots; I never see anything on the console and I never get to the debugger. So, as I say, very easy to reproduce the problem, just create a zraid pool of any type with more than 9 member disks, dump some data to it, then try to read it back, and the machine will reboot. If I create a pool with 9 or fewer disks, the system seems perfectly stable. I was never able to reproduce the reboot behavior as long as the pools contained 9 or fewer drives, beating on it fairly hard with iozone and multiple current dd operations writing large files to and from memory. Just wondering if anyone's seen this problem before and as to whether or not it is a known bug and may have been fixed in STABLE or CURRENT? Should I report this as a bug? Should I just create pools of 9 or fewer drives? Not sure if my customer is going to want to use STABLE or CURRENT in production but I wanted to run this by the list just to see. Best, -Sean
Sean Thomas Caron
2010-Oct-20 17:26 UTC
Spurious reboot in 8.1-RELEASE when reading from ZFS pool with > 9 disks
Hi Lawrence, Interesting; have you tried this for raidz2 as well? I just created a raidz2 pool with 5 disks and then added another 5 disk raidz2 to it, so, total of 10 disks in the pool (though this is ultimately a losing strategy unless the number of disks is >> 9 because two drives are lost for parity in each sub-raid in the pool). It (seemed) just slightly more stable than creating a single raidz2 pool with > 9 disks but it still crashes. I guess this does allow me to say its more an issue of number of devices in the pool versus capacity of the pool because with the parity drives taken out, the pool with two 5-disk raidz2s has less total capacity than a pool with a single 9-disk raidz2. Just out of idle curiousity, I also tried it with raidz1 on my system. Again, I created a 5-disk pool, raidz1 this time, then added another 5-disk raidz1 to the pool for, again, total of 10 disks. Again, a bit of a losing strategy versus creating one great big raidz unless the number of disks is >> 9 because of losing a disk in each sub-raidz1 in the pool for parity but less so of course than raidz2. This seemed to crash too, same behavior. Are you using 8.1-RELEASE or STABLE or ...? Best, -Sean> > I have a 16 disk pool, if you create it with > > zpool create poolname raidz disk1 disk2 disk3 etc > > then > > zpool add poolname raidz disk8 disk9 disk10 etc > > You get the full size pool and no issues. > > pool: tank > state: ONLINE > scan: scrub repaired 0 in 0h0m with 0 errors on Wed Oct 20 14:54:08 2010 > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > da0 ONLINE 0 0 0 > da1 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 0 > da4 ONLINE 0 0 0 > da5 ONLINE 0 0 0 > da6 ONLINE 0 0 0 > da7 ONLINE 0 0 0 > raidz1-1 ONLINE 0 0 0 > da8 ONLINE 0 0 0 > da9 ONLINE 0 0 0 > da10 ONLINE 0 0 0 > da11 ONLINE 0 0 0 > da12 ONLINE 0 0 0 > da13 ONLINE 0 0 0 > da14 ONLINE 0 0 0 > da15 ONLINE 0 0 0 > > errors: No known data errors >
Jeremy Chadwick
2010-Oct-20 18:08 UTC
Spurious reboot in 8.1-RELEASE when reading from ZFS pool with > 9 disks
On Wed, Oct 20, 2010 at 11:27:38AM -0400, Sean Thomas Caron wrote:> I've been playing with ZFS in 8.1-RELEASE (amd64) on a Sun Fire > X4500 with 16 GB RAM and in general it seems to work well when used > as recommended. > > BUT... > > In spite of the suggestion of Sun and FreeBSD developers to the > contrary, I have been trying to create some zraid pools of size > greater than 9 disks and it seems to give some trouble. > > If I try to create a pool containing more than 9 [500 GB] disks, > doesn't matter if it is zraid1 or zraid2, the system seems to reboot > given any amount of sustained reads from the pool (haven't tested > mirrored pools). Now, I am not sure of: > > - Whether the reboot in the zraid1 case is caused by exactly the > same issue as the reboot in the zraid2 case > > - Whether this is an issue of total number of member disks, or total > amount of disk space in the pool. All I have to work with at the > moment is 500 GB drives. > > I am not doing any sysctl tuning; just running with the defaults or > what the system automatically sizes. I tried playing around with > tuning some sysctl parameters including setting arc_max to be very > small and it didn't seem to help any; pools of greater than 9 disks > in size are always unstable. > > Writes seem to work OK; I can, say, pull stuff from over the network > and save it to the pool, or I can do something like, > > dd if=/dev/random of=/mybigpool/bigfile bs=1024 size=10M > > and it will write data all day pretty happily. But if I try to read > back from the pool, for example, > > dd if=/mybigpool/bigfile of=/dev/null bs=1024 > > or even to just do something like, > > cp /mybigpool/bigfile /mybigpool/bigfile_2 > > the system reboots pretty much immediately. I never see anything on > the console at all; it just reboots. > > Even if I build a new kernel with debugging options: > > options KDB > options DDB > > the system still just reboots; I never see anything on the console > and I never get to the debugger. > > So, as I say, very easy to reproduce the problem, just create a > zraid pool of any type with more than 9 member disks, dump some data > to it, then try to read it back, and the machine will reboot. > > If I create a pool with 9 or fewer disks, the system seems perfectly > stable. I was never able to reproduce the reboot behavior as long as > the pools contained 9 or fewer drives, beating on it fairly hard > with iozone and multiple current dd operations writing large files > to and from memory. > > Just wondering if anyone's seen this problem before and as to > whether or not it is a known bug and may have been fixed in STABLE > or CURRENT? Should I report this as a bug? Should I just create > pools of 9 or fewer drives? Not sure if my customer is going to want > to use STABLE or CURRENT in production but I wanted to run this by > the list just to see.There are users here using FreeBSD ZFS with *lots* of disks (I think someone was using 32 disks at one point) reliably. Some of them post here regularly (with other issues that don't consist of sporadic reboots). The kernel options may not be sufficient. I'm used to using these: # Debugging options options BREAK_TO_DEBUGGER # Sending a serial BREAK drops to DDB options KDB # Enable kernel debugger support options KDB_TRACE # Print stack trace automatically on panic options DDB # Support DDB options GDB # Support remote GDB And in /etc/rc.conf, setting: ddb_enable="yes" Next: arc_max isn't "technically" a sysctl, meaning it can't be changed in real-time, so I'm not sure how you managed to do that. Validation: sysctl: oid 'vfs.zfs.arc_max' is a read only tunable sysctl: Tunable values are set in /boot/loader.conf Your system may be reporting something relating to kmem exhaustion but is then auto-rebooting so fast that you can't see the message on VGA console. Do you have serial console? Please try setting the following tunables in /boot/loader.conf and reboot the machine, then see if the same problem persists. vm.kmem_size="16384M" vfs.zfs.arc_max="14336M" vfs.zfs.prefetch_disable="1" vfs.zfs.zio.use_uma="0" vfs.zfs.txg.timeout="5" I would also advocate you try 8.1-STABLE as there have been many changes in ZFS since then (and I'm not just referring to the v15 import), including how the ARC gets sized/adjusted. CURRENT is highly bleeding-edge, so I would start or stick with STABLE. Finally, there's always the possibility that the PSU has some sort of load problem with that many disks all being accessed at the same time. I imagine the power draw of that system is quite high. I can't imagine Sun shipping a box with a insufficient PSU, but then again power draw changes depending on the RPM of the disks used and many other things. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |