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. > 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
