On Sat, 4 Nov 2006, Mikulas Patocka wrote:
> 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.
After 65536 crashes you have to run spadfsck --reset-crash-counts. Maybe I
add that functionality to kernel driver too, so that it will be formally
corect.
Is there any reason you can not make these fields 64 or even 128 bits in
size to increase these "limits" dramatically?
Thanks,
Grzegorz Kulewski
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[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]
