linux-kernel - Re: [git pull] first batch of ufs fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 11 Jun 2017 22:30:44 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Richard Narron <comet.berkeley@...il.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [git pull] first batch of ufs fixes

On Sun, Jun 11, 2017 at 12:47:40PM -0700, Richard Narron wrote:

> 1) Creating an OpenBSD 6.1 (44bsd) disk and then on Linux copying a large >
> 2GB file and creating a directory, there are errors on OpenBSD
> with the fsck:
> 
> OpenBSD (44bsd):
>   #fsck sd0e
>   ** /dev/rsd0e
>   ** File system is already clean
>   ** Last Mounted on /diske
>   ** Phase 1 - Check Blocks and Sizes
>   ** Phase 2 - Check Pathnames
>   ** Phase 3 - Check Connectivity
>   ** Phase 4 - Check Reference Counts
>   ** Phase 5 - Check Cyl groups
>   FREE BLK COUNT(S) WRONG IN SUPERBLK
>   SALVAGE? [Fyn?]
>   3 files, 1272410 used, 6983197 free (13 frags, 872898 blocks, 0.0% fragmentation)
> 
>   ***** FILE SYSTEM WAS MODIFIED *****
> 
> And also after removing the files on Linux, there were errors in
> the fsck on OpenBSD:
> 
>   #fsck sd0e
>   ** /dev/rsd0e
>   ** File system is already clean
>   ** Last Mounted on /diske
>   ** Phase 1 - Check Blocks and Sizes
>   ** Phase 2 - Check Pathnames
>   ** Phase 3 - Check Connectivity
>   ** Phase 4 - Check Reference Counts
>   ** Phase 5 - Check Cyl groups
>   FREE BLK COUNT(S) WRONG IN SUPERBLK
>   SALVAGE? [Fyn?]
>   1 files, 1 used, 8255606 free (14 frags, 1031949 blocks, 0.0% fragmentation)
> 
>   ***** FILE SYSTEM WAS MODIFIED *****

Interesting...  The main difference between UFS1 and UFS2 in that area
is the misbegotten rotation latency optimizations (always ugly as hell,
pointless by mid-90s, dropped completely in UFS2 and dropped in FreeBSD
UFS1 in 2002, at the same time when Kirk had merged UFS2).  I hadn't
looked at OpenBSD situation, but their filesystem and VFS side tends
to be, er, somewhat antique.  So that would be my first guess; I'll
resurrect openbsd-in-KVM setup here and see what's really going on...

> 2) The available block counts on a newly created FreeBSD 11.0
>     ufs2 filesystem (13079640) differ from Linux 4.12-rc4 (13079656):
> 
> Freebsd (ufs2):
>   #df /diske
>   Filesystem   1K-blocks Used    Avail Capacity  Mounted on
>   /dev/ada0s3e  14217008    8 13079640     0%    /diske
> Linux:
>   #df /fbsd23
>   Filesystem     1K-blocks  Used Available Use% Mounted on
>   /dev/sda23      14217008     8  13079656   1% /fbsd23

Linux:
        buf->f_bavail = (buf->f_bfree > (((long)buf->f_blocks / 100) * uspi->s_minfree))
                ? (buf->f_bfree - (((long)buf->f_blocks / 100) * uspi->s_minfree)) : 0;
FreeBSD:
	sbp->f_bavail = freespace(fs, fs->fs_minfree) +
            dbtofsb(fs, fs->fs_pendingblocks);
#define freespace(fs, percentreserved) \
        (blkstofrags((fs), (fs)->fs_cstotal.cs_nbfree) + \
        (fs)->fs_cstotal.cs_nffree - \
        (((off_t)((fs)->fs_dsize)) * (percentreserved) / 100))

Note that all those values are in units of fragments, so the size is
not 14217008, it's 3554252.  Now, you clearly have minfree at 8 and
we get (3554252/100)*8 vs. (3554252*8)/100, i.e. 284336 and 284340
respectively.  There's your 16Kb of difference...

> 3) The available block counts on a newly created NetBSD 7.1
>     ufs2 filesystem (9518316) differ from Linux 4.12-rc4 (9518314):
> 
> NetBSD (ufs2):
>   #df /nbsdf
>   Filesystem     1K-blocks  Used Available Use% Mounted on
>   /dev/sda22      10019278     2   9518316   1% /nbsdf
> Linux:
>   #df /diskf
>   Filesystem    1K-blocks       Used      Avail %Cap Mounted on
>   /dev/wd0f      10019278          2    9518314   0% /diskf

Huh?  The other way round?  I'm fairly sure you've mislabeled those -
/dev/wd* makes a plausible NetBSD device name, but /dev/sda22 doesn't.
And "Use%" vs "%Cap" also points in the same direction.  If the first
one is on Linux and the second on NetBSD, I'm fairly certain that it's
the same story.  And if it is, I'm not sure it's worth worrying about -
the difference will never be greater than minfree * fragment size, and
that's pretty much noise.