The thing is that the opaque URL is interpreted only on the TFile
construction time, so the settings might have been overwritten if the
same file handle was used to fill a TTreeCache.
Lukasz
On Thu, Jan 27, 2011 at 5:20 PM, Brian Bockelman <[log in to unmask]> wrote:
> Hi Lukasz,
>
> This is not happening during a ReadV operation, if that's what you're asking.
>
> There's a lot of trees here and several TTreeCaches present. At this point, we're not in the middle of filling the TTreeCache.
>
> Brian
>
> On Jan 27, 2011, at 11:14 AM, Lukasz Janyst wrote:
>
>> Are you reading a tree via ttreecache?
>>
>> Lukasz
>>
>> On Thu, Jan 27, 2011 at 5:04 PM, Brian Bockelman <[log in to unmask]> wrote:
>>> Hi Lukasz,
>>>
>>> Here's a bit higher of a level of debug:
>>>
>>> 110127 16:57:13 001 Xrd: Read: Read(offs=2664306755, len=104)
>>> 110127 16:57:13 001 Xrd: Read: Cache response: got 104@2664306859 bytes. Holes= 0 Outstanding= 0
>>> 110127 16:57:13 001 Xrd: Read: Found data in cache. len=104 offset=2664306755
>>> 110127 16:57:13 001 Xrd: Read: Read(offs=2664371953, len=1149)
>>> 110127 16:57:13 001 Xrd: Read: Cache response: got 0@2664371953 bytes. Holes= 1 Outstanding= 0
>>> 110127 16:57:13 001 Xrd: Read: Hole in the cache: offs=2664371953, len=1149
>>> 110127 16:57:13 001 Xrd: Read_Async: Requesting to read 16384 bytes of data at offset 2664366080
>>> 110127 16:57:13 001 Xrd: Read_Async: Requesting pathid 0
>>> 110127 16:57:13 001 Xrd: Read: Waiting 1outstanding blocks.
>>> 110127 16:57:13 16248 Xrd: ProcessUnsolicitedMsg: Incoming unsolicited response from streamid 3
>>> 110127 16:57:13 16248 Xrd: ProcessUnsolicitedMsg: Processing async response from streamid 3 father=2
>>> 110127 16:57:13 16248 Xrd: ProcessUnsolicitedMsg: Putting kXR_read data into cache. Offset=2664366080 len 16384
>>>
>>> This is the URL used:
>>>
>>> root://xrootd.unl.edu//store/data/Run2010B/BTau/AOD/Dec4ReReco_v1/0007/B26C2B64-E101-E011-9C89-002481E14F38.root?readaheadsz=32768&cachesz=3276800&readaheadstrategy=1&readtrimblksz=16384
>>>
>>> So, it seems readtrimblksz works and cachesz/readaheadsz doesn't.
>>>
>>> Brian
>>>
>>> On Jan 27, 2011, at 10:46 AM, Lukasz Janyst wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> it looks like there are two possibilities:
>>>>
>>>> * if you're not using a ttreecache: you have disabled the readahead by
>>>> configuring an unknown readahead strategy in the environment
>>>> * if you're reading from a ttree through a ttreecache: the readahead is disabled
>>>>
>>>> Cheers,
>>>> Lukasz
>>>>
>>>> On Thu, Jan 27, 2011 at 4:20 PM, Brian Bockelman <[log in to unmask]> wrote:
>>>>> Hi,
>>>>>
>>>>> I'm opening a file with the following opaque data:
>>>>>
>>>>> root://xrootd.unl.edu:1094//store/data/Run2010B/BTau/AOD/Dec4ReReco_v1/0007/B26C2B64-E101-E011-9C89-002481E14F38.root?readaheadsz=32768&cachesz=327680
>>>>>
>>>>> I.e., I would expect the minimal read size is 32KB. However, I see the following read pattern:
>>>>>
>>>>> 110127 16:11:34 001 Xrd: Read: Hole in the cache: offs=2673920000, len=55
>>>>> 110127 16:11:34 001 Xrd: Read: Hole in the cache: offs=2673920512, len=145
>>>>> 110127 16:11:34 001 Xrd: Read: Hole in the cache: offs=2673921024, len=70
>>>>> 110127 16:11:34 001 Xrd: Read: Hole in the cache: offs=2673921536, len=154
>>>>> 110127 16:11:34 001 Xrd: Read: Hole in the cache: offs=2673922048, len=24
>>>>> 110127 16:11:35 001 Xrd: Read: Hole in the cache: offs=2673922560, len=162
>>>>>
>>>>> I would have expected all these reads to be handled by the cache. This is with ROOT 5.27.06b.
>>>>>
>>>>> Brian
>>>>>
>>>>>
>>>
>>>
>
>
|