> On Mar 6, 2018, at 10:33 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
>
> On Mon, Mar 05, 2018 at 05:49:26PM -0500, Steve Dickson wrote:
>>
>>
>> On 03/05/2018 04:53 PM, J. Bruce Fields wrote:
>>> On Mon, Mar 05, 2018 at 10:54:20AM -0500, Steve Dickson wrote:
>>>> Signed-off-by: Steve Dickson <steved@xxxxxxxxxx>
>>>> ---
>>>> support/nfs/nfs_mntent.c | 3 ++-
>>>> utils/blkmapd/device-discovery.c | 6 ++++--
>>>> utils/mount/network.c | 8 ++++++--
>>>> utils/nfsd/nfssvc.c | 5 +++--
>>>> utils/statd/statd.c | 3 ++-
>>>> 5 files changed, 17 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/support/nfs/nfs_mntent.c b/support/nfs/nfs_mntent.c
>>>> index a2118a2..c60988a 100644
>>>> --- a/support/nfs/nfs_mntent.c
>>>> +++ b/support/nfs/nfs_mntent.c
>>>> @@ -150,7 +150,8 @@ nfs_addmntent (mntFILE *mfp, struct mntent *mnt) {
>>>> res = fflush(mfp->mntent_fp);
>>>> if (res < 0)
>>>> /* Avoid leaving a corrupt mtab file */
>>>> - ftruncate(fileno(mfp->mntent_fp), length);
>>>> + if (ftruncate(fileno(mfp->mntent_fp), length))
>>>> + {/* ignore return value */};
>>>
>>> Might be worth a log warning?
>> Yes... I thought about that. But I could not think of any meaningful
>> log that would help diagnose the problem... The ftruncate() is basically
>> cleanly up a mess..
>>
>> Maybe log an error message from the fflush()?
>
> Yeah, and I admit maybe it's not worth anything specifically by the time
> the ftruncate also fails.
Acknowledging that fact in the comment might be a good idea.
--
Chuck Lever
--
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
