On 10/19/2011 01:40 PM, Jeff Layton wrote: > On Wed, 19 Oct 2011 13:30:58 -0400 > Steve Dickson <SteveD@xxxxxxxxxx> wrote: > >> >> >> On 10/19/2011 01:22 PM, Jeff Layton wrote: >>> On Wed, 19 Oct 2011 13:10:19 -0400 >>> Steve Dickson <SteveD@xxxxxxxxxx> wrote: >>> >>>> >>>> >>>> On 10/19/2011 12:36 PM, Jeff Layton wrote: >>>>> On Wed, 19 Oct 2011 11:34:30 -0400 >>>>> Steve Dickson <steved@xxxxxxxxxx> wrote: >>>>> >>>>>> This patch is a following on to commit 7a802337. Using the >>>>>> tool in https://bugzilla.redhat.com/show_bug.cgi?id=695916 >>>>>> caused the fflush() and fclose() to fail in turn causing >>>>>> corruption in the mtab. >>>>>> >>>>>> The failures were in the internals of both calls. Switch those >>>>>> calls with the actual system calls eliminated the failures. >>>>>> >>>>>> Signed-off-by: Steve Dickson <steved@xxxxxxxxxx> >>>>>> --- >>>>>> support/nfs/nfs_mntent.c | 4 ++-- >>>>>> 1 files changed, 2 insertions(+), 2 deletions(-) >>>>>> >>>>>> diff --git a/support/nfs/nfs_mntent.c b/support/nfs/nfs_mntent.c >>>>>> index a2118a2..b80f270 100644 >>>>>> --- a/support/nfs/nfs_mntent.c >>>>>> +++ b/support/nfs/nfs_mntent.c >>>>>> @@ -117,7 +117,7 @@ void >>>>>> nfs_endmntent (mntFILE *mfp) { >>>>>> if (mfp) { >>>>>> if (mfp->mntent_fp) >>>>>> - fclose(mfp->mntent_fp); >>>>>> + close(fileno(mfp->mntent_fp)); >>>>>> if (mfp->mntent_file) >>>>>> free(mfp->mntent_file); >>>>>> free(mfp); >>>>>> @@ -147,7 +147,7 @@ nfs_addmntent (mntFILE *mfp, struct mntent *mnt) { >>>>>> free(m3); >>>>>> free(m4); >>>>>> if (res >= 0) { >>>>>> - res = fflush(mfp->mntent_fp); >>>>>> + res = fsync(fileno(mfp->mntent_fp)); >>>>> >>>>> fsync doesn't imply an fflush. With this, I think you may end up >>>>> without everything being committed to disk if part or all of it is >>>>> still in the file stream buffer. You probably want to do an fflush() >>>>> and then an fsync here. >>>> The problem was with the fflush() call. The call was causing the >>>> mount to drop core in turn causing mtab corruption. Changing that >>>> call to a fsync() worked just fine... no corruption... every time! >>>> >>> >>> Ahh, then you have another problem here too then. Most likely it was >>> crashing because it caught a SIGXFSZ. Writing out the mtab should not >>> be affected by signals. >> So calling fflush() generates a SIGXFSZ and call fsync() does not... >> I really don't see what the problem is is call simply calling fsync() >> which clearly works? >> > > Because they do different things. fflush() flushes out the (userspace) > stream buffer to the kernel's pagecache. fsync() forces the pagecache > to be written out and committed to disk. Believe I understand the code...... > > If you call fsync() while the data is still in the userspace buffer > then it doesn't really do you any good. The data you wrote via fwrite() > won't be committed to disk. > So I'm thinking the reason the data makes it the disk is its already in the pagecache when the fsync() is called... but to agree with Bruce, the might just be luck... steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
