linux-kernel - Re: New filesystem for Linux

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]

Message-ID: <Pine.LNX.4.64.0611031057410.26057@twinlark.arctic.org>
Date:	Fri, 3 Nov 2006 11:00:58 -0800 (PST)
From:	dean gaudet <dean@...tic.org>
To:	Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>
cc:	Jörn Engel <joern@...nheim.fh-wedel.de>,
	linux-kernel@...r.kernel.org
Subject: Re: New filesystem for Linux

On Fri, 3 Nov 2006, Mikulas Patocka wrote:

> > On Thu, 2 November 2006 22:52:47 +0100, Mikulas Patocka wrote:
> > > 
> > > new method to keep data consistent in case of crashes (instead of
> > > journaling),
> > 
> > Your 32-bit transaction counter will overflow in the real world.  It
> > will take a setup with millions of transactions per second and even
> > then not trigger for a few years, but when it hits your filesystem,
> > the administrator of such a beast won't be happy at all. :)
> > 
> > Jörn
> 
> If it overflows, it increases crash count instead. So really you have 2^47
> transactions or 65536 crashes and 2^31 transactions between each crash.

it seems to me that you only need to be able to represent a range of the 
most recent 65536 crashes... and could have an online process which goes 
about "refreshing" old objects to move them forward to the most recent 
crash state.  as long as you know the minimm on-disk crash count you can 
use it as an offset.

-dean

p.s. i could see a network device with spotty connectivity causing a large 
bump in crash count in a short period of time.