[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: [dm-devel] Re: [RFC] New Logging approach for Device Mapper



On Sun, Sep 6, 2009 at 5:03 AM, Alasdair G Kergon <agk redhat com> wrote:
> > Each logging type is represented with 2 bits in 
> dm_logging_level. Following are the logging types currently defined :
> 
> Does that mean there's a limit we'll soon exceed?

Yes true. In that case we can further split the logging across the targets , such as multipath, linear so on. Your thoughts please.

> 
> > Sep  5 18:32:02 localhost kernel: device-mapper: core: 
> DEBUG: dm_resume: Unsetting DMF_SUSPENDED flag for 253:1
> 
> I was hoping the next extension to the macro code would 
> somehow add info
> like '253:1' (and maybe corresponding device name) automatically to
> every message related to a device.
> 

Ok. I will so that.

> 
> But do we really need this level of runtime debugging configurability?
> I can't say I've come across problems where I'd have needed it: Can 
> anyone else offer examples where it would have helped them?
> 

Both approaches ("without level" and "with level") looks fine to me. Advantage with going for "Without level" approach is that we will be having further more space for defining log types. 

Advantage with "with level" approach is that it will log more relevant logs. Just giving a hypothetical example here, Lets assume I/O getting killed during all path failure condition when no_path_retry feature was set. To debug that I may want to check what all messages communicated from userspace to kernel. Also I may want to check DM_NOFLUSH_FLAG being set properly here. For the same I would set following log levels:

---------------------------
LOG TYPES		LOG LEVEL
----------------------------
DM_IOCTL		DM_INFO       --> It will print all the communication between userspace and kernel space
DM_IO			DM_ERR        --> It will tell exactly where I/O error was hit.


"without level" approach in this scenario will log more messages here in comparison.

Third approach I could think of it is having flexible level. i.e we can ignore levels for those types which populates syslog less(such as DM_INIT, DM_FAILOVER ..) and can have levels for those which are logging heavily (such as DM_IO, DM_IOCTL .. ). But it may add some complexity in calculating and setting the log levels. 

Your thoughts.

Thanks,
Vijay


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]