Project

General

Profile

Actions

Feature #21578

closed

Add debug logging option to arvados-client mount

Added by Tom Clegg about 2 months ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Story points:
-

Description

When invoked as

arvados-client mount --log-level=debug ...

when an error code is returned to a fuse API call ("I/O error") the original (typically much more informative) error message should also be logged to the terminal.


Subtasks 1 (0 open1 closed)

Task #21592: Review 21578-mount-debugResolvedTom Clegg03/21/2024Actions

Related issues

Related to Arvados Epics - Idea #17849: FUSE driver v2NewActions
Actions #1

Updated by Tom Clegg about 2 months ago

Actions #2

Updated by Tom Clegg about 2 months ago

  • Description updated (diff)
Actions #3

Updated by Brett Smith about 2 months ago

arvados-client mount --log-level=debug ...

There's an existing arv-mount option called --logfile. It would be nice to accept --loglevel for symmetry. (If we also accept --log-level, fine.)

There is an existing --debug option that should be a shortcut for --loglevel=debug.

Actions #4

Updated by Peter Amstutz about 2 months ago

  • Target version set to Development 2024-03-27 sprint
Actions #5

Updated by Tom Clegg about 1 month ago

fwiw, costanalyzer, deduplicationreport, diagnostics, and recovercollection already accept "-log-level", and afaict we don't have anything that accepts "-loglevel".

Actions #6

Updated by Tom Clegg about 1 month ago

21578-mount-debug @ b290de5604e7ccfad230cd1e0547f0c09cc2fe01 -- developer-run-tests: #4085

Example logs after doing some things like "ls asdfasdf", "mkdir asdfasdf":

DEBU[2024-03-15T11:26:00.742594509-04:00] fuse call returned error                      errno=-2 error="file does not exist" op=Getattr path=/by_id/asdfasdf
DEBU[2024-03-15T11:26:00.742743817-04:00] fuse call returned error                      errno=-2 error="file does not exist" op=Getattr path=/by_id/asdfasdf
DEBU[2024-03-15T11:26:07.672947349-04:00] fuse call returned error                      errno=-2 error="file does not exist" op=Getattr path=/by_id/asdfasdf
DEBU[2024-03-15T11:26:07.673209837-04:00] fuse call returned error                      errno=-38 error="invalid operation" op=Mkdir path=/by_id/asdfasdf
DEBU[2024-03-15T11:26:53.625915417-04:00] fuse call returned error                      errno=-2 error="file does not exist" op=Getattr path=/abcdefg
DEBU[2024-03-15T11:26:53.626102196-04:00] fuse call returned error                      errno=-2 error="file does not exist" op=Getattr path=/abcdefg
DEBU[2024-03-15T11:26:53.626174517-04:00] fuse call returned error                      errno=-2 error="file does not exist" op=Getattr path=/abcdefg
DEBU[2024-03-15T11:27:02.328901455-04:00] fuse call returned error                      errno=-2 error="file does not exist" op=Getattr path=/abcdefg
DEBU[2024-03-15T11:27:09.657885275-04:00] fuse call returned error                      errno=-2 error="file does not exist" op=Getattr path=/abcdefg
DEBU[2024-03-15T11:27:09.658023614-04:00] fuse call returned error                      errno=-38 error="invalid operation" op=Mkdir path=/abcdefg
DEBU[2024-03-15T11:27:52.142643769-04:00] fuse call returned error                      errno=-2 error="file does not exist" op=Getattr path=/by_id/jutro-4zz18-nm6dir7pkhhbrf3/abcdefg
Actions #7

Updated by Brett Smith about 1 month ago

Tom Clegg wrote in #note-5:

fwiw, costanalyzer, deduplicationreport, diagnostics, and recovercollection already accept "-log-level", and afaict we don't have anything that accepts "-loglevel".

My personal philosophy about this is, it's ideal for everything to be consistent, but local consistency trumps wider consistency. Consistency within one tool's options is more important than consistency across tools. So if the goal is to eventually make this a drop-in replacement for arv-mount, and it's going eventually grow a --logfile option, then the --loglevel option would be best for local consistency.

But that's just, like, my opinion, man.

Actions #8

Updated by Tom Clegg about 1 month ago

I suppose we can get both kinds of consistency by having arvados-client mount accept -log-level, and (eventually? or should we do this now?) -log-file for symmetry and -logfile for compatibility with arv-mount.

Actions #9

Updated by Brett Smith about 1 month ago

Tom Clegg wrote in #note-8:

I suppose we can get both kinds of consistency by having arvados-client mount accept -log-level, and (eventually? or should we do this now?) -log-file for symmetry and -logfile for compatibility with arv-mount.

Yes, that would work fine. From a process perspective, I'm very worried we're going to repeat the history of Workbench 2, where we promise feature parity, and then later problems with arv-mount cause us to promote arvados-client mount before we implement feature parity, and then we just give up. To prevent history from repeating, I think it would be good if we implemented interface parity at the same time that we implement functionality parity, rather than planning to develop it separately later. But, obviously I'm not "supposed" to worry about this, it's not my call to make, it's Peter's.

Actions #10

Updated by Tom Clegg about 1 month ago

Right. I was assuming we would want to implement interface parity (-logfile == -log-file) at the same time as functionality parity. I was just trying to ask whether that time is now, or later.

Arguably -logfile functionality is not just about sending logs to a file instead of stderr, but also about writing crunchstat-style metrics as logs, which I definitely don't want to scope-creep into this ticket.

Actions #11

Updated by Tom Clegg about 1 month ago

21578-mount-debug @ cb68d4e34688abd308d7adffc288c82a5deb6c85 -- developer-run-tests: #4091

adds -debug alias for -log-level=debug, and merges main to fix tests.

Actions #12

Updated by Brett Smith about 1 month ago

Tom Clegg wrote in #note-11:

21578-mount-debug @ cb68d4e34688abd308d7adffc288c82a5deb6c85 -- developer-run-tests: #4091

LGTM, thanks.

Actions #13

Updated by Tom Clegg about 1 month ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF