On 2016-09-20 13:54, Chris Murphy wrote:
It really is. I've done this before, but I had a copy of the on-disk
format documentation, a couple of working filesystems, a full copy of
the current kernel sources for reference, and about 8 cups of green tea
(my beverage of choice for staying awake and focused). I got _really_
lucky and it was something that really was simple to fix once I found it
(it amounted to about 64 bytes of changes, it took me maybe 5 minutes to
actually correct the issue once I found where it was), but it took me a
good couple of hours to figure out what to even look for, plus another
hour just to find it, and I'm not sure I would be able to do it any
faster if I had to again (unlike doing so for ext4, which is a walk in
the park by comparison).
On Tue, Sep 20, 2016 at 11:03 AM, Alexandre Poux <pums...@gmail.com> wrote:
If I wanted to try to edit my partitions with an hex editor, where would
I find infos on how to do that ?
I really don't want to go this way, but if this is relatively simple, it
may be worth to try.
Simple is relative. First you'd need
https://btrfs.wiki.kernel.org/index.php/On-disk_Format to get some
understanding of where things are to edit, and then btrfs-map-logical
to convert btrfs logical addresses to physical device and sector to
know what to edit.
I'd call it distinctly non-trivial and very tedious.
TBH the only thing I'd worry about using a hex editor to fix in BTRFS is
the super-blocks or system chunks, because they're pretty easy to find,
and usually not all that hard to fix. In fact, if it hadn't been for
the fact that I had no backup of the data I would lose by recreating
that filesystem, and I was _really_ bored that day, I probably wouldn't
have even tried.
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html