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.
Mikulas
-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.
-
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]
