| Message ID | cover.1564505777.git.dsterba@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Sysfs updates | expand |
On Tue, Jul 30, 2019 at 07:10:07PM +0200, David Sterba wrote: > Export the potential debugging data in the per-filesystem directories we > already have, so we can drop debugfs. The new directories depend on > CONFIG_BTRFS_DEBUG so they're not affecting normal builds. > > David Sterba (2): > btrfs: sysfs: add debugging exports > btrfs: delete debugfs code Pushed to misc-next.
On 7/31/19 1:10 AM, David Sterba wrote: > Export the potential debugging data in the per-filesystem directories we > already have, so we can drop debugfs. The new directories depend on > CONFIG_BTRFS_DEBUG so they're not affecting normal builds. > > David Sterba (2): > btrfs: sysfs: add debugging exports > btrfs: delete debugfs code > > fs/btrfs/sysfs.c | 68 +++++++++++++++++++++++------------------------- > fs/btrfs/sysfs.h | 5 ---- > 2 files changed, 32 insertions(+), 41 deletions(-) > For 2/2: Reviewed-by: Anand Jain <anand.jain@oracle.com> For 1/2: IMO it would be better to delay this until we really have a debug hook exposed at the sysfs. Thanks, Anand
On Tue, Aug 06, 2019 at 11:17:09PM +0800, Anand Jain wrote: > On 7/31/19 1:10 AM, David Sterba wrote: > > Export the potential debugging data in the per-filesystem directories we > > already have, so we can drop debugfs. The new directories depend on > > CONFIG_BTRFS_DEBUG so they're not affecting normal builds. > > > > David Sterba (2): > > btrfs: sysfs: add debugging exports > > btrfs: delete debugfs code > > > > fs/btrfs/sysfs.c | 68 +++++++++++++++++++++++------------------------- > > fs/btrfs/sysfs.h | 5 ---- > > 2 files changed, 32 insertions(+), 41 deletions(-) > > > > For 2/2: > Reviewed-by: Anand Jain <anand.jain@oracle.com> > > For 1/2: > IMO it would be better to delay this until we really have a debug hook > exposed at the sysfs. Sorry, I don't understand what you mean.
On 7/8/19 12:46 AM, David Sterba wrote: > On Tue, Aug 06, 2019 at 11:17:09PM +0800, Anand Jain wrote: >> On 7/31/19 1:10 AM, David Sterba wrote: >>> Export the potential debugging data in the per-filesystem directories we >>> already have, so we can drop debugfs. The new directories depend on >>> CONFIG_BTRFS_DEBUG so they're not affecting normal builds. >>> >>> David Sterba (2): >>> btrfs: sysfs: add debugging exports >>> btrfs: delete debugfs code >>> >>> fs/btrfs/sysfs.c | 68 +++++++++++++++++++++++------------------------- >>> fs/btrfs/sysfs.h | 5 ---- >>> 2 files changed, 32 insertions(+), 41 deletions(-) >>> >> >> For 2/2: >> Reviewed-by: Anand Jain <anand.jain@oracle.com> >> >> For 1/2: >> IMO it would be better to delay this until we really have a debug hook >> exposed at the sysfs. > > Sorry, I don't understand what you mean. > I notice that /sysfs/fs/btrfs/<debug>|<fsid/debug> is dummy as of now, IMO its better to add this (1/2) patch along with the some actual trace which is needed. Potentially either dtrace/bfp probes will be better runtime debugging approach. Thanks, Anand
On Wed, Aug 07, 2019 at 04:29:45PM +0800, Anand Jain wrote: > On 7/8/19 12:46 AM, David Sterba wrote: > > On Tue, Aug 06, 2019 at 11:17:09PM +0800, Anand Jain wrote: > >> On 7/31/19 1:10 AM, David Sterba wrote: > >>> Export the potential debugging data in the per-filesystem directories we > >>> already have, so we can drop debugfs. The new directories depend on > >>> CONFIG_BTRFS_DEBUG so they're not affecting normal builds. > >>> > >>> David Sterba (2): > >>> btrfs: sysfs: add debugging exports > >>> btrfs: delete debugfs code > >>> > >>> fs/btrfs/sysfs.c | 68 +++++++++++++++++++++++------------------------- > >>> fs/btrfs/sysfs.h | 5 ---- > >>> 2 files changed, 32 insertions(+), 41 deletions(-) > >>> > >> > >> For 2/2: > >> Reviewed-by: Anand Jain <anand.jain@oracle.com> > >> > >> For 1/2: > >> IMO it would be better to delay this until we really have a debug hook > >> exposed at the sysfs. > > > > Sorry, I don't understand what you mean. > > > > I notice that /sysfs/fs/btrfs/<debug>|<fsid/debug> is dummy as of now, > IMO its better to add this (1/2) patch along with the some actual trace > which is needed. Yes it is empty for now, ready for use, like was the previous debugfs. I don't want to delay removing the debugfs code further and not providing a replacement does not sound as a good option, the patch would be lost in the mailinglist. > Potentially either dtrace/bfp probes will be better > runtime debugging approach. That's orthogonal, the sysfs is for exporting data or triggering some action by writing to the files. The file based approach is simple to use without external tools like bpf or even 3rd party patchsets like dtrace.