linux-ext4 - Re: tune2fs -l stale info

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:	Tue, 03 Apr 2007 15:55:57 +0200
From:	Vincent Caron <vcaron@...rstech.com>
To:	Andreas Dilger <adilger@...sterfs.com>
Cc:	ext3-users@...hat.com, linux-ext4@...r.kernel.org
Subject: Re: tune2fs -l stale info

On jeu, 2007-03-29 at 13:59 -0600, Andreas Dilger wrote:
> On Mar 29, 2007  14:17 +0200, Vincent Caron wrote:
> >   I just noticed that 'tune2fs -l' did not returned a "lively" updated
> > information regarding the free inodes count (looks like it's always
> > correct after unmounting).
> 
> This is a bit of a defect in all 2.6 kernels.  They never update the
> on disk superblock free blocks/inodes information to avoid lock contention,
> even if this info is available.

  It turns out it is okay in my case since 'df -i' reports correct
numbers.

> Can you please give the following patch a try?  It fixes this issue,
> and also makes statfs MUCH more efficient for large filesystems, because
> the filesystem overhead is constant unless the filesystem size changes
> and checking that for 16k groups is slow (hence hack to add cond_resched()
> instead of fixing problem correctly).  It has not been tested much, but
> is very straight forward.
> 
> Only the last part is strictly necessary to fix your particular problem
> (setting of es->s_free_inodes_count and es->s_free_blocks_count).  This
> is lazy, in the sense that you need a "statfs" to update the count, and
> then a truncate or unlink or rmdir in order to dirty the superblock to
> flush it to disk.  However, it will be correct in the buffer cache, and
> it is a lot better than what we have now.  We don't want a non-lazy version
> anyways, because of performance.

  Unfortunately the problem shows on a production machine and I don't
have a similar one to test properly (it's a heavy-loaded filer).

  BTW, if ondisk superblocks are not updated until specific events occur
(umount, statfs), what is the consequence of a system crash ? Does
journalization come into play (superblock=metadata?), does fsck fixes
figures from other ondisk structures ? Just being curious...

-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html