On Mon, Sep 21, 2020 at 10:23:55PM +0300, Juha Erkkilä wrote:
>
>
> > On 16. Sep 2020, at 20.27, Juha Erkkilä <juha...@icloud.com> wrote:
> >
> >
> >> On 16. Sep 2020, at 0.18, Kenneth Gober <kgo...@gmail.com> wrote:
> >> I took a very quick look at the source and it appears that 213 is shown in
> >> octal. I believe that the 200 bit indicates that a core file was produced,
> >> and 13 is probably a signal number (13 octal equals 11 decimal which would
> >> be SIGSEGV). I am not sure whether the size of the file system is itself
> >> the cause, I have been using dump(8) to back up a large (currently 6.7TB)
> >> volume to tape for years (several tapes, actually) and it works fine,
> >> although that system is still on 6.1/amd64. I looked in CVS and didn't see
> >> any obvious diffs between 6.1 and 6.6 that jumped out at me as potential
> >> causes, so perhaps the issue has been latent for a long time and I haven't
> >> seen it because it's triggered by the particulars of one or more files
> >> rather than the overall file system size. Maybe if an individual file gets
> >> too big, or is too 'sparse' or something?
> >
> > I can reproduce this on -current from Fri Sep 11 11:30:09
> > with a freshly created and an empty filesystem of 2 terabytes.
>
> It looks like the same issue has been fixed in
> FreeBSD: https://svnweb.freebsd.org/base?view=revision&revision=334979
> <https://svnweb.freebsd.org/base?view=revision&revision=334979>
>
> The diff applies cleanly to the current OpenBSD source tree.
Maybe by hand, but not by using patch(1), the context differs a bit.
Next obvious question: did you test if it fixes your problem? That
means, do you get a dump that can be restored again?
-Otto
