From: Stan Seibert (volsung@physics.utexas.edu)
Date: Mon Sep 26 2005 - 09:34:49 CDT
>> That might be a feature of ROOT, actually. It is known to do this
>> to avoid large file problems on some systems. Was the original
>> file near 1 or 2 GB in size? (I don't remember which is the limit
>> these days)
>>
>
> They both are 1.8 GB. For some reason, I didn't think it would be
> a root feature. I will investigate it more to see what I come up
> with.
We've had the same problem with root file output in the SNO software
as well, with about the same crashing issues later. It generally
seems to be a bad idea to let ROOT do the file splitting (not to
mention that you won't know ahead of time how many files you are
going to get, complicating your job scripts.) The solutions are either:
a) Run smaller jobs, but more of them (not a bad idea for robustness
against job failure)
b) Increase the ROOT filesize limit. ROOT defaults to treating 1.9GB
as the size barrier, but since ver 4.02, they switched to 64-bit file
indexing. So, assuming your OS is happy with large files, you can
call the static class method
TTree::SetMaxTreeSize(Long64_t maxsize)
at the start of your program, and all trees created after that point
will have the new limit. This should "just work" on recent Linux
distributions. We'll have to check RedHat 7.3 and Solaris 8 to make
sure there aren't any lurking gotchas.
>> Also, which operating system are you seeing the problems on?
>>
>
> gentoo Linux
Ah, good. I was hoping it was a bug in my code logic (as this would
suggest) rather than a difference between how operating systems
handle signals.
--- Stan Seibert
This archive was generated by hypermail 2.1.6 : Tue Sep 27 2005 - 00:01:02 CDT