On Wed, May 11, 2016 at 07:55:57PM +0800, Anand Jain wrote: > > * current default is to print the device name -- so this would mean a > > forced change in defaults > > * the FSID is not very human friendly. I can remember several device > > names and I'll probably know which filesystem is on which > > * the FSID is very long, consumes half of the line before the actual > > message starts > > Yes, indeed. I think we discussed that there isn't any other > alternative as well. Also I was thinking something like in > the 'git log --online' output but that might conflict in some > cases ? (recently there was a progs patch which fixed the short fsid > hash conflict).
You mean a shorter UUID? The first four bytes (8 hexa digits) seem unique enough. That can be optinal I think. > > I understand the benefits of automated filtering by FSID, but we have > > conflicting interests here. If you're going to deploy automated log > > scanning, you probably have automated the filesystem mkfs & mount, so > > it's a matter of configuration to get it done and in one place. > > Makes sense. > > Actually automated scripts wasn't in my discussion, I was thinking > of support engineers debugging customer issues using hand written > scripts. I'm not sure how far should we forsee problems that somebody else may theoretically encounter. Providing grounds for easy navigation and searchability in the logs is on our side, but if somebody does not know how to properly look for them, that's not our problem. > Probably we could taken an experimental project, to have these > logs in cvs format, and use external scripts to monitor and > debug. Make something like splunk.com an easy job. As far as the format stays parseable, everybody should be ok. CSV does not sound like a good idea to me though. > >> 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 ? > > > > I don't think that looking up device names is making troubleshooting > > significantly harder and never found it to be a problem in my past > > experienes. > > > > Besides, errors from lower layers report the device names, so bad > > sectors or failed writes pop up very quickly in the searches. > > Right. FSID won't provide that advantage. > > > Either way, I'm willing to make it configurable so it addresses all > > usecases. > > > > Another way came to my mind: make it a module parameter, so > > even the mount option or sysfs settings is not needed and the defaults > > are system-wide. > > Yep. This helps. > I was thinking from the angle of support engineers, who would > solve customers issues (it happens at most of the Linux vendors), > They would write/run scripts on their own to understand the problem > from the kernel logs. So now it can be assured that logs format > would remain same per distribution/vendor. I was working in support for a few years and have an experience with digging in the logs. There was a lot of custom scripting and grepping needed as the problem reports were mostly unique. Some tasks were common so one script doing an initial analysis could be reused without modifications, but otherwise it's not like running a script that would do all the work. Anyway, this is getting too abstract, I'd like to address specific problems. I'm fine with adding the configurable logging options. -- 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
