linux-ext4 - Re: lifetime_write_kbytes isn't preserved during unclean shutdown

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] [day] [month] [year] [list]

Date:	Wed, 30 Jun 2010 15:54:02 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	tytso@....edu
Cc:	Nebojsa Trpkovic <trx.lists@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: lifetime_write_kbytes isn't preserved during unclean shutdown

On 2010-06-30, at 07:31, tytso@....edu wrote:
> On Tue, Jun 29, 2010 at 11:46:57PM -0600, Andreas Dilger wrote:
>> Could we also update the superblock blocks/inodes free counters at
>> that time as well?
> 
> Remind me again why you wanted it.  You had some use case where you
> wanted to be able to read the file system's block device directly and
> have vaguely correct free inode/block numbers in the superblock?

That is so that running "e2fsck -fn" on a quiet filesystem does not complain.  I always find this annoying that it fails with the inode and blocks counters being incorrect, even though the filesystem has been idle for hours.

It would also be possible to fix e2fsck not to complain about this for a read-only e2fsck run (as it already does with "e2fsck -fy").  However, the last I recall from that approach was that you didn't want it to return 0 if there was anything that actually needed fixing.

>> One way to do this would be to have a JBD transaction pre-commit
>> callback, and if the superblock has not been written in N seconds
>> then it can be added as part of that transaction (if it will fit).
>> If it is already in the transaction it can be updated via the
>> existing bh callbacks that OCFS2 is using.
> 
> That seems reasonable way of doing things.  I think N seconds should
> be in the region of every 5-60 minutes, though.  And yes, absolutely
> we wouldn't want to spin up the disk if there was no other activity.

I didn't say how big "N" would be :-).

It may be easier to have the _first_ handle started after N seconds where the superblock was not updated add in the superblock to the transaction, and then the superblock buffer gets updated just before transaction close time with whatever we want to stick in there.

Cheers, Andreas

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