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