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.
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
