On 05/10/2016 03:42 PM, David Sterba wrote:
On Tue, May 10, 2016 at 10:34:19AM +0800, Anand Jain wrote:
On 05/09/2016 05:39 PM, David Sterba wrote:
Currently we lack the identification of the filesystem in most if not
all mount messages, done via printk/pr_* functions. We can use the
btrfs_* helpers in open_ctree, as the fs_info <-> sb link is established
at the beginning of the function.
While here I also recommend to pass fs_devices instead of fs_info
to btrfs_printk(). That's mainly because before the fs is mounted
we don't have fs_info, however fs_devices exists in both the mounted
and unmount context. If you agree, I could send a patch on top of
your patch.
Yeah, before we mount we don't have fs_info. My idea was to provide
another set of functions that would take something else than fs_info to
print the filesystem identifier.
Switching btrfs_err & others to fs_devices everywhere would be too
invasive.
right.
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 ?
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.
Thanks, Anand
Otherwise the rest below looks fine.
Thnaks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
