kevanbrown
Dabbler
- Joined
- Mar 19, 2012
- Messages
- 17
Each time I upgrade between FreeNAS 8.0.x builds, one or more of my NFS/ZFS volumes reports data corruption shortly after the nightly system status report is generated. I don't know if the timing is related or not, but regardless the data corruption is quite a large inconvenience.
Environment:
Dell PowerEdge 1900 with High Point Tech RocketRAID 2314 attached to a Sans Digital 8-bay SATA disk enclosure. There are 8 HDD's in the enclosure and the RocketRAID 2314 is configured with hardware RAID enabled and 4 mirrors are create of the 8 HDDs in the enclosure. ZFS volumes are then create atop these hardware RAID mirror logical drives and then NFS shares to export them for use with VMware ESX 5.0 running on two Dell PowerEdge T410 servers.
Process resulting in issue:
I perform a web upgrade of my current FreeNAS 8.0.x build to the latest FreeNAS 8.0.x build (I'm usually only one build behind). After the first nightly system status report is generated (3:00AM), my virtual machine backups for one or more virtual machines begin to fail and checksum errors are logged by ZFS, resulting in I/O errors and data corruption. I have tried deleting and restoring the virtual machine files from backup, but this doesn't seem to completely resolve the checksum errors on the volume and I am finally required to completely destroy and recreate the underlying ZFS volume and NFS share, then restore the backups and everything is usually fine from then on. As it sounds, this process does require hours of work and downtime after each FreeNAS upgrade and subsequent data corruption.
My last upgrade (just this past weekend) was from FreeNAS 8.0.3-p2 to 8.0.4. The same data corruption condition eventually reared its ugly head once again.
With this latest build upgrade, I also noted that while monitoring /var/log/messages via the web console for the barrage of ZFS I/O checksum failure events, after a while I was suddenly unable to access the management address of the FreeNAS system. I ran ifconfig bce0 down and ifconfig bce0 up to resolve the issue and was once again able to access the FreeNAS web console. I'm unsure what may have caused this, but I've not seen this particular issue in previous upgrades (just the data corruption issue).
Regards,
Kevan
Environment:
Dell PowerEdge 1900 with High Point Tech RocketRAID 2314 attached to a Sans Digital 8-bay SATA disk enclosure. There are 8 HDD's in the enclosure and the RocketRAID 2314 is configured with hardware RAID enabled and 4 mirrors are create of the 8 HDDs in the enclosure. ZFS volumes are then create atop these hardware RAID mirror logical drives and then NFS shares to export them for use with VMware ESX 5.0 running on two Dell PowerEdge T410 servers.
Process resulting in issue:
I perform a web upgrade of my current FreeNAS 8.0.x build to the latest FreeNAS 8.0.x build (I'm usually only one build behind). After the first nightly system status report is generated (3:00AM), my virtual machine backups for one or more virtual machines begin to fail and checksum errors are logged by ZFS, resulting in I/O errors and data corruption. I have tried deleting and restoring the virtual machine files from backup, but this doesn't seem to completely resolve the checksum errors on the volume and I am finally required to completely destroy and recreate the underlying ZFS volume and NFS share, then restore the backups and everything is usually fine from then on. As it sounds, this process does require hours of work and downtime after each FreeNAS upgrade and subsequent data corruption.
My last upgrade (just this past weekend) was from FreeNAS 8.0.3-p2 to 8.0.4. The same data corruption condition eventually reared its ugly head once again.
With this latest build upgrade, I also noted that while monitoring /var/log/messages via the web console for the barrage of ZFS I/O checksum failure events, after a while I was suddenly unable to access the management address of the FreeNAS system. I ran ifconfig bce0 down and ifconfig bce0 up to resolve the issue and was once again able to access the FreeNAS web console. I'm unsure what may have caused this, but I've not seen this particular issue in previous upgrades (just the data corruption issue).
Regards,
Kevan