True.. It'll probably be a long timeuntil it's even worth considering, however... the loss would be 4 bytes/block which is almost nothing. The gain otoh would be easier mirating the DS in the future.
One other thing to consider is bugs. Imagine that freenet devl has to go under ground and continue only on FN. Then a bug in the DS-handling when it's time to change would be really harmful for the whole net. Sure, it will probably never become a problem, but it's better to be on the safe side. Especially if the cost is 4 bytes/32k. I vote _for_ the change. Not because it's needed now, but that it will be sometime, and environmental things may change radically 'til then. // Dennis (cyberdo) On Fri, 17 Feb 2006, Ian Clarke wrote: > No. Most filesystems have a total maximum disk size of 2TB - breaking > compatibility to support 64TB datastores isn't worth it, and probably won't > be for a decade. Personally I think the obsession some people have with > ridiculously large datastores is misplaced anyway. > > Ian. > > On 17 Feb 2006, at 17:28, Matthew Toseland wrote: > >> Is it worth breaking backwards compatibility for the 0.7 datastore (with >> prior builds of 0.7) to fix an inherent 64TB limit? >> >> The code uses an int for offsets into files, which is easily fixed. >> However it also uses, on disk, an int for block numbers. This means >> datastores are limited to 2G * 32K = 64TB. Normally I wouldn't regard >> this as a big problem, but since we are in pre-alpha, and since there >> isn't that much content, I'm inclined to make the change... >> -- >> Matthew J Toseland - toad at amphibian.dyndns.org >> Freenet Project Official Codemonkey - http://freenetproject.org/ >> ICTHUS - Nothing is impossible. Our Boss says so. >> _______________________________________________ >> Tech mailing list >> Tech at freenetproject.org >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech >
