> On 6. Jun 2021, at 10:10, Patrick Welche <prlw1%cam.ac.uk@localhost> wrote: > > On Sat, Jun 05, 2021 at 06:45:24PM +0200, J. Hannken-Illjes wrote: >> Patrick, >> >> please try the attached diff so the "spcl.c_addr" test >> no longer runs off the spcl record. >> >> "blks" is used for multi-tape checkpointing and examining >> TS_INODE/TS_ADDR records should be sufficient as the are >> the only records that support holes in data. > > Thanks! With your patch, the dump | restore has been happily > running for about 12 hours now. Ok, will commit and request pullup next week. > In your previous email you mention: > >> This trace makes no sense, bitmaps (CLRI and BITS) don't have holes >> and therefore ignore the "c_addr" array. I have no idea how dumping >> a bitmap ends in the hole processing of flushtape(). > > Is it worth investigating further while I have the reproducer? No, this is an error that manifests on file systems with many inodes and therefore did not raise before. -- J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig
Attachment:
signature.asc
Description: Message signed with OpenPGP