Date: Thu, 25 Jun 2015 13:41:50 -0400 From: RA H <rah.lists@gmail.com> To: freebsd-fs@freebsd.org Subject: VFS buffering issues with UFS + soft-updates journaling Message-ID: <CAFzyudixCBu17NfmFyhoB_1d7g5qfH9p-53WEpOykXOjsUD7Yw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
I was directed here by a moderator on the official forums, who suggested the behaviour I'm seeing may be a bug. I don't have much experience with mailing lists, so please be gentle :) I'm experiencing data loss on a UFS filesystem on an iSCSI disk when the iSCSI connection is terminated abruptly. I know the issue isn't that the data doesn't have time to flush to disk; unmounting the filesystem right after the copy completes always returns immediately. Details: FreeBSD 10.1-RELEASE iscsictl(8) (ie. the new iSCSI initiator) single GPT partition on disk UFS with soft-update journaling I mount the fs, copy a 1G file (have tried source file on tmpfs and a local SATA disk), wait ~10 seconds, then pull the Ethernet cable on the NIC which is connected to the iSCSI disk. I then reboot gracefully with shutdown -r now. After the system comes back up a fsck is necessary; I answer y to all the questions. After mounting, I either find no evidence the file ever existed, a file of zero size, or a truncated file. Even calling sync before terminating the connection does not prevent data loss. The first indication the problem had something to do with buffering was that during the reboot, the buffer sync (ie. Syncing disks, buffers remaining...) always indicates something in the range of 20-50 buffers that need syncing, all of which are eventually given up on. As a workaround, I set the sysctl variable vfs.lodirtybuffers to 1. With this setting, it takes 2-3 seconds for the sysctl variable vfs.numdirtybuffers to return to the level it was before the I started the copy. At that point I can pull the ethernet cable, reboot (there are still a few buffers that don't get synced), fsck, etc. and the file is intact. I haven't seen any side-effects to this, but I expect setting it so low is not exactly best practice. Another workaround is using UFS without soft-updates or journaling, provided I sync before terminating the iSCSI connection. The sync actually does what's expected in this case, and although fsck is still required, AFAICT it only needs to mark the fs clean. Initial testing with UFS and gjournal seems to work without OOTB, but I'm not sure I want to go that route.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFzyudixCBu17NfmFyhoB_1d7g5qfH9p-53WEpOykXOjsUD7Yw>