Re: UFS s_maxbytes bogosity

[Richard Narron <comet.berkeley@gmail.com>]

On Thu, 8 Jun 2017, Al Viro wrote:

> On Mon, Jun 05, 2017 at 04:49:36AM +0100, Al Viro wrote:
>
>> Grrr...  OK, I'll put together a patch fixing that idiocy.  As it is, rw mounts
>> of ufs on-disk ->i_blocks not updated and, AFAICS, can lead to disk space leaks
>> on inode deletion.
>
> Turns out it's even worse than that, and some of the breakage in there is my fault.
> I'll fix what I can, but for now I would suggest
> 	* making UFS_FS_WRITE depend on BROKEN; it had always been experimental,
> but since 2010 it had been actively buggering filesystems (aforementioned Jan's
> bug + a bug of mine in 2015 series).  I'll fix that stuff, but I'd expect
> it to take a month or so, including serious testing.  I have set the things up
> for such testing (which has promptly caught all kinds of fun), but we are at -rc4
> now, so it'll probably be the next cycle fodder, with interesting backporting
> afterwards.
> 	* for ->s_maxbytes, let's go with tree-imposed limit.  Proper way of
> dealing with ->i_blocks overflows is -ENOSPC when attempt to grab a block would've
> caused such an overflow.
> 	* If Evgeniy can resurface and take part in that fun, I'd be happy to help.
> If not, well... guess I'll take the thing over until somebody willing to adopt it
> comes along.

I am willing to test.  I just turned on UFS_FS_WRITE for the very first 
time running 4.12-rc4 and was able to copy a file of more than 2GB from 
one r/o FreeBSD subpartition to another r/w FreeBSD subpartition.

So it is already looking pretty good.

I did notice an ->i_blocks bug where it was set to zero on the output file 
instead of the actual block count.  This showed up when I poped over to FreeBSD 11.0 and 
did an fsck on the r/w subpartition.