On 11/28/25 3:18 PM, Kevin Wolf wrote: > Am 28.11.2025 um 13:24 hat Andrey Drobyshev geschrieben: >> On 11/27/25 6:39 PM, Kevin Wolf wrote: >>> Am 27.11.2025 um 15:31 hat Andrey Drobyshev geschrieben: >>>> As for reflink copy, this might've been a great solution. However, it >>>> would largely depend on the FS used. E.g. in my system coredumpctl >>>> places uncompressed coredump at /var/tmp, which is mounted as ext4. And >>>> in this case: >>>> >>>> # cp --reflink /var/tmp/coredump-MQCZQc /root >>>> cp: failed to clone '/root/coredump-MQCZQc' from >>>> '/var/tmp/coredump-MQCZQc': Invalid cross-device link >>>> >>>> # cp --reflink /var/tmp/coredump-MQCZQc /var/tmp/coredump.ref >>>> cp: failed to clone '/var/tmp/coredump.ref' from >>>> '/var/tmp/coredump-MQCZQc': Operation not supported >>>> >>>> Apparently, ext4 doesn't support reflink copy. xfs and btrfs do. But I >>>> guess our implementation better be FS-agnostic. >>> >>> Yes, we might still need a slow copy fallback for those filesystems, >>> i.e. essentially a 'cp --reflink=auto'. For myself, coredumps will >>> generally live on XFS, so I would benefit from creating that copy in the >>> same filesystem where the coredump lives, and for you it shouldn't hurt >>> at least. >>> >>> Another thought... it's a bit crazy, but... we're QEMU, we have our own >>> tools for this. We could create a qcow2 overlay for the coredump and >>> export it using FUSE! :-D (Probably not very practical because you need >>> the right paths for the binaries, but I had to mention it.) >>> >>> Kevin >> >> We can surely add reflink copying as a fast path option which we try >> first. That's cheap to implement. The real issue is designing a >> sensible fallback approach. > > I mean, as far as I am concerned, you can keep what you already have as > the fallback approach. Reflink copy if possible, and otherwise a slow > full copy. > > Or if the coredump can be written to, you could do the in-place editing, > though I would save the original content in a file that could survive a > crash. And after finishing the operation, the original content > definitely should be written back. >
I decided to go with the latter approach as it's more universal. In-place modifying doesn't take as much time, so performance difference with reflink shouldn't be a problem. I've sent v2 with an implementation. >> As for creating an overlay... That's an interesting option but it would >> require everybody who wants to use this stuff configure their QEMU build >> with --enable-fuse. We, for instance, don't have it enabled in our >> builds, as I'm sure many others. >> >> Of course we can think of an NBD export for such an overlay instead of >> FUSE. But it'll then require root user to write to /dev/nbd0. Also not >> very acceptable. >> >> Quick overlayfs mount with lowerdir=/var/tmp could also solve this. But >> again, root is required. Not good. >> >> So the most robust option, I guess, is the one suggested by Daniel: >> copying some kind of minimal viable coredump part/range instead of the >> whole file, which is just enough for producing valid backtrace. The >> only thing left is figuring out which part to copy. That might require >> some tricky ELF structure parsing. > > All of these solutions are interesting, but honestly feel a bit too > complex for a simple debugging script. > > Kevin >
