On 5/10/18 4:36 PM, hal@xxxxxxxxxxxx wrote:
From: Hal Pomeranz <hal@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
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 -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
