While filling a ROOT TFile with about 600 TTrees a user of my program has reported the following error:
SysError in <TFile::WriteBuffer>: error writing to file F:/Auswertung/GENEPI_combined/dataRMA.root (-1) (No space left on device)
followed by:
This error is symptomatic of a Tree created as a memory-resident Tree
Instead of doing:
TTree *T = new TTree(...)
TFile *f = new TFile(...)
you should do:
TFile *f = new TFile(...)
TTree *T = new TTree(...)
which is repeated many times.
The strange thing is that his hard disk had still 95GB free space!
Thus my question is:
Do you have any idea what might be the reason for this error?
Could it be that the hard dsik is too fragmented, so that the ROOT file can no longer be filled?
What is the behavior of ROOT when creating/filling trees on WinXP?
Does ROOT need consecutive disk space (on WinXP) when filling a file with trees?
I forgot to mention that the error occurs only when he calls the single function “rma()”, which does background-correction, quantile-normalization and summarization in one step. However, when he used separate functions for each step, he could finish the computation w/o problem. The trees created were identical, the only difference was that in the first case all trees were saved in a single root file, whereas in the second case the different trees were saved in three different root files.
Can you explain why you think that it may be a problem of virtual memory?
Furthermore, do you think that hard disk fragmentation could be a problem?
As I am surely not able to reproduce the error which the user of my program gets on WinXP (although I have installed WinXP on my Mac using BootCamp to test my program), I would really appreciate your opinion.
Regarding your suggestion:
Do you know how to monitor the memory, virtual memory and disk behavior on WinXP if you do not want to watch the TaskManager for a couple of hours?
[quote]I forgot to mention that the error occurs only when he calls the single function “rma()”, which does background-correction, quantile-normalization and summarization in one step. However, when he used separate functions for each step, he could finish the computation w/o problem. The trees created were identical, the only difference was that in the first case all trees were saved in a single root file, whereas in the second case the different trees were saved in three different root files.[/quote]Did the user use 3 different TFile object or only one in the failing case? Is there any threading involved?
Then I am a bit at a loss . The only possible explanation I can still think of would be if the single TFile is closed and reopened ‘quickly’ (but even that would be a stretch) … does the problem still happens?
[quote] Does ROOT need consecutive disk space (on WinXP) when filling a file with trees?[/quote]No. Actually we do not know, nor care how the file is physically laid-out (but the logical layout is consecutive).
[quote]Does a TTree need consecutive disk space or is it dependent on the size of the baskets?[/quote]Same answer, we do not access the physcial file, we only access it though the logical view offered by the posix interface.
This is sad, since this may be the problem for the following reason:
The root file that is created can sometimes have a size of few GigaBytes (or even more),
and since it is known that on WinXP the hard disk becomes fragmented, then there may
be not enough consecutive space on the HD even though it has enough overall space.
For this reason it would be important to know the answer to these questions.
IF there is a requirement that the ROOT file be physically consecutive on the disk, then it IS a bug in the Microsoft implementation of the posix file i/o interface ; the posix standard does not make any requirement of sort (and that why most file are actually in little piece on a windows disk). I do not believe there is such a bug and thus do not believe that there is any such requirement …
. The only possible explanation I can still think of would be if the single TFile is closed and reopened ‘quickly’ (but even that would be a stretch) … does the problem still happens?