Re: [PATCH] xfs_db: add blockget -L option

[Eric Sandeen <sandeen@sandeen.net>]

On 5/10/18 4:36 PM, hal@deer-run.com wrote:
> From: Hal Pomeranz <hal@deer-run.com>
> 
> Allow blockget on a mounted file system or "dirty" file system image
> with pending log entries-- by simply ignoring the log.  This makes
> xfs_db more useful for forensics where we are often dealing with these
> types of images.  Flushing log entries to disk by mounting/unmounting
> the file system would allow us to use blockget, but would make changes
> to the file system state which are not desirable in forensics contexts.
> 
> Signed-off-by: Hal Pomeranz <hal@deer-run.com>

Well, I'm back on the fence about this one; I know I steered you in
this direction, but after talking to dchinner a bit, he raised some valid
concerns about adding an option which essentially makes the tool behave
in unpredictable ways (by trying to traverse an inconsistent filesystem).

I had jumped to the conclusion that the usecase was for examining an
offline filesystem image without needing to perturb it by replaying the
log; Dave pointed out that you're talking about using this on a live
filesystem, and even baking this behavior into other higher level tools.
That kind of opened my eyes to all the ways this can go wrong.  :(

Thus spake Dave:

> IMO, the only thing worse than not having a forensic tool for a
> specific job is having a forensic tool provided by a trusted toolkit
> whose results are unreliable and cannot be trusted....

...

> I'd suggest, in that case, that you limit it's use to off-line or
> read-only snapshots of online filesystems? This would mean that the
> results of xfs_db operations (while eceedingly slow) will be
> reliable.

And in both of those cases, you won't need to ignore a dirty log.
Especially with teh express stated purpose of examining live
filesystems, I really hate to give you this much rope.

Stuff like parent pointers and fsmap are (eventually) going to give
you a much better way to achieve what (I think) you want, here.

-Eric