Re: [PATCH] btrfs: switch to common message helpers in open_ctree, adjust messages

[Anand Jain <anand.jain@oracle.com>]

On 05/10/2016 10:28 PM, David Sterba wrote:
> On Tue, May 10, 2016 at 04:40:58PM +0800, Anand Jain wrote:
>>
>>
>> On 05/10/2016 04:21 PM, David Sterba wrote:
>>> On Tue, May 10, 2016 at 04:01:05PM +0800, Anand Jain wrote:
>>>>> In more detail:
>>>>>
>>>>> * introduce _btrfs_printk that takes a string pointer as 1st argument
>>>>>      (this could be used for messages before fs_info exists)
>>>>> * _btrfs_printk(NULL, ...) will be valid
>>>>> * then btrfs_printk(fs_info, ...) will become a wrapper
>>>>>      _btrfs_printk(btrfs_sb(fs_info)->s_id, ...)
>>>>> * _btrfs_err & others do not need to be introduced, we can use the
>>>>>      standard KERN_ERR
>>>>
>>>>     Does it mean logs when fs_info is not available won't have fsid ?
>>>
>>> Right, we don't have fsid until we read the superblock from disk
>>> (somewhere in open_ctree).
>>
>>    Not only at open_ctree. We create fs_devices with fsid when 'btrfs dev
>>    scan' and we do populate btrfs_fs_devices->fsid this is well before
>>    open_ctree is called. OR open_ctree may not be called at all in some
>>    cases.
>
> So in this case we'd need to transform the fsid (from any source) to the
> string before passing to the proposed _btrfs_printk.
>
>>>>     Except for the logs in the context such as modload.. which does not
>>>>     involve a disk. Consistency in logging would help. Like fishing-out
>>>>     all logs related to a FSID.
>>>
>>> Yeah, this is probably related to your patches switching the messages to
>>> print fsid instead of device. Consistency is desirable of course, though
>>> we might need to make the output style configurable.
>>
>>    If there is something that works simple, better. I am fine.
>>
>>    Generally servers may have more than one fs mounted. So filter
>>    by fsid comes handy. Without worrying about when it was labeled,
>>    and troubleshooting scripts to fail.
>
> The idea is:
>
>    mount -o log=fsid /dev/sda /mnt/path


  This makes life of a 3rd party troubleshooter more difficult. As it
  needs to be understood what mount option was used, and if its not
  changed in between by the customer, and if the logs by filter won't
  show some of the critical logs, would lead to a wrong analysis of
  the issue.

  But whats the concern for print FSID by default (without having to
  come through the -o log=fsid) ?


  Just my understanding:
  For real end users we need to provide everything at the cli output.
  That is without asking them to refer to dmesg in the cli out put. IMO.
  (I could be wrong). Troubleshooters are the people looking at dmesg.
  So finding the FSID can be expected ?

  Further there is nothing avoids user not to label two FS with the
  same label.

Thanks, -Anand


> where the message will print the fsid in place of device:
>
>    BTRFS info (uuid bcf91f8e-03bb-4e90-9546-24f0564c92a1): disk space caching is enabled
>
> also could be tunable after mount via a sysfs file. Possibly we can also
> allow to print the label.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>