On 12/13/2010 02:32 PM, Steve Dickson wrote:
> Hey...
>
> On 12/13/2010 12:08 PM, Chuck Lever wrote:
>
>>>> */
>>>> @@ -863,10 +879,15 @@ nsm_load_host(const char *directory, const char *filename, nsm_populate_t func)
>>>> if (path == NULL)
>>>> goto out_err;
>>>>
>>>> - if (stat(path, &stb) == -1) {
>>>> + if (lstat(path, &stb) == -1) {
>>>> xlog(L_ERROR, "Failed to stat %s: %m", path);
>>>> goto out_freepath;
>>>> }
>>>> + if (!S_ISREG(stb.st_mode)) {
>>>> + xlog(D_GENERAL, "Skipping non-regular file %s",
>>>> + path);
>>> Question, why do we care non-regular files are being ignored?
>>
>> We probably want to report anything unexpected in
>> the /var/lib/nfs/statd/sm{,.bak} directories.
>>
>>> I understand logging the lstat() error but logging statements like
>>> "ignoring this" or "not doing that" just make the debug output a
>>> bit too noisy IMHO...
>>
>> My expectation is that under normal circumstances this message
>> would never fire.
> Correct the only way they will be shown is with the "-F -d" flags...
>
>> statd shouldn't put anything in that directory
>> that isn't a regular file. If there's something else in there,
>> we should report it. Also, if statd (or something else) is broken
>> and the code thinks the object isn't a regular file, then this
>> message would point to what is wrong.
> To put this in context, here are the message that come up with
> the patch applied... I added a symlink to /var/lib/nfs/statd/sm/statd
> to generate both messages...
>
> statd: Version 1.2.3 starting
> statd: Flags: No-Daemon Log-STDERR TI-RPC
> sm-notify: Version 1.2.3 starting
> sm-notify: Already notifying clients; Exiting!
> statd: Skipping dot file ..
> statd: Skipping non-regular file /var/lib/nfs/statd/sm/statd
> statd: Skipping dot file .
This does fix true bug, so I am going to commit the patch
but without the "Skipping dot file" statements and leaving
the "Skipping non-regular" ones since they will never be
seen...
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
