Re: .hotfiles.btree
Re: .hotfiles.btree
- Subject: Re: .hotfiles.btree
- From: Eric Tamura <email@hidden>
- Date: Wed, 20 Aug 2008 15:55:05 -0700
On 19 Aug 2008, at 6:49 PM, Gerriet M. Denkmann wrote:
On 20 Aug 2008, at 05:02, Eric Tamura wrote:
Response inline...
On 19 Aug 2008, at 12:09 AM, Gerriet M. Denkmann wrote:
Some questions about .hotfiles.btree which are not answered by
tn1150 (all quotes from there).
2. The only case where a .hotfiles.btree seems to work is my boot
partition. Known bug, feature, or error on my side?
Hotfiles are only supported on the root filesystem. Other
filesystems do not get hotfiles support.
I assume that "root filesystem" = partiton mounted on "/" = boot
partition. Correct?
Yes that is the case.
4. When does the hotfiles.btree gets updated? Who or what triggers
the update? Is possible to tell someone in charge to update the
hotfiles.btree right now? By sending some signal to some process?
Files are added and removed to the hotfiles list as vnodes are
reclaimed and recycled. When the file goes out of scope, it goes
through a bunch of checks for the temperature, who its parent is,
the current hotfiles stage, among other things. If it passes all
of the checks it is added to the hotfiles list. There isn't a way
to trigger update of the hotfiles btree from userland via signals.
It would be nice if an update to the hotfiles btree would set the
modifyDate of /.hotfiles.btree .
If this is important, please file a radar.
5. "The fork's temperature can be computed by dividing its
clumpSize by its totalBlocks." This formula does not give results
even close to the things I see.
temperature = clumpSize * blockSize (4096) / logicalSize gives
more plausible results.
But even so some entries do not make sense.
E.g.:
[ forkType 0 temperature 3458460 fileID 486463 ] = "Users"
[RootFolder nodeName: "Users"]
fileID = 486463 flags: hasThread
Creator: 1919443312 = 'rhap'
HfsType: 1936485995 = 'slnk'
Data Fork:
logicalSize 28 (bytes)
clumpSize 147
totalBlocks 1 (4096 bytes)
With my formula I get a temperature = 21,504 instead of 3458460
in the hotfiles.btree.
Also anything cooler than 10 000 degrees Celsius (or Kelvin?) has
temperatures in the hotfiles.btree which are much too low;
obviously not updated since ages.
But threshold (minimum temperature): 24
And timeleft = 0.8 days and never changing.
The formula is basically as as described. bytes read / Total
blocks used by the fork. The only difference is that instead of
using the clump value on-disk, HFS uses the data from the in-core
data structures. The data structures could be out of sync from the
in memory values, though I'm not sure that that would describe the
discrepancies. How are you obtaining the information above?
I have a small (homegrown) programm which reads and displays
partitions.
Looking at the hot files, I see some strange or at least surprising
things:
1. The vast number of the hottest files are never used by me (they
appear to be used exclusively by periodic.weekly when it is
"Rebuilding whatis database")
e.g. [ forkType 0 temperature 17262 fileID 467221 ] = y1.3 = "y1.3"
2. Somebody (not me!) does use (and rather hotly too!) some
unexpected languages:
[ forkType 0 temperature 12368 fileID 100323 ] = Info =
"InfoPlist.strings"
/Applications/TextEdit.app/Contents/Resources/ko.lproj/
InfoPlist.strings
accessed: 2008-08-20 07:16:17 +0700
logicalSize 1448 (bytes)
clumpSize 4379
3. many entries with a temperature = 4 seem really out of sync: the
data stored (first 4 bytes of filename) are mostly wrong:
e.g.: [ forkType 0 temperature 4 fileID 1504294 ] = bull =
"15461.html"
/Applications/iTunes.app/Contents/Resources/no.lproj/iTunes Help/pgs/
15461.html
Who did ever use Norwegian on this computer?
I would advise checking the endian swapping code in your tool then.
Note that if you are running on an Intel many HFS fields will need to
be endian swapped before after read in from disk. They must all be
swapped again when writing data to the disk, too. I've been victim to
bugs like this in the past.
I would also make sure the CNID values you're seeing with your tool
the same as those that can be pulled from a tool like stat(2).
-Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden