ldmwndletsm
ADSM.ORG Senior Member
- Joined
- Oct 30, 2019
- Messages
- 232
- Reaction score
- 5
- Points
- 0
How can I determine the file size for an object when running from the server?
Every time I've played with that, it either never matches the size of the file on disk, or the command just hangs interminably. Maybe this gets into aggregates and such. I don't know, but as an example, when running 'q content volume f=d', the 'Stored Size' never matches, even if 'Aggregated' is No and Segment Number is 1/1. I looked at thobias.org, but very confusing, and I'm unclear if the answer is really in there. I'm not interested in the sum aggregate of all objects of a file space. I need the sizes of the constituent files.
Obviously, I can go to the client, but I might have to do this on multiple machines, so I would prefer to run this from the server. Clearly, the client doesn't store this information anywhere other than the client log, but that's not where it's pulling it from when running 'q backup path -detail'. In fact, I don't think the client even reports the size other than in the log, does it?
Anyway, I tried this from the server to report the file sizes and file names for every object under /filespace for nodename:
select backups.FILESPACE_NAME, HL_NAME, LL_NAME, ACTUAL_SIZE, BACKUP_DATE, contents.FILE_SIZE from backups, contents where backups.NODE_NAME='nodename' and backups.FILESPACE_NAME='/filespace' and backups.object_id=contents.object_id"
but it just sits there and never prints anything. If I remove the join, and only print information from one table or the other then it's as fast as a speeding car. But even if the above command ever does decide to finally report something, I'm dubious if the 'ACTUAL_SIZE' and/or FILE_SIZE is what I need here. I tried both, hence the join, but when using just ACTUAL_SIZE and no join, the value is always empty for any LL_NAME.
On a related note, why is the client able to report its information so quickly? For example, something like: q backup /path -detail? What tables or columns is it referencing on the server?
Every time I've played with that, it either never matches the size of the file on disk, or the command just hangs interminably. Maybe this gets into aggregates and such. I don't know, but as an example, when running 'q content volume f=d', the 'Stored Size' never matches, even if 'Aggregated' is No and Segment Number is 1/1. I looked at thobias.org, but very confusing, and I'm unclear if the answer is really in there. I'm not interested in the sum aggregate of all objects of a file space. I need the sizes of the constituent files.
Obviously, I can go to the client, but I might have to do this on multiple machines, so I would prefer to run this from the server. Clearly, the client doesn't store this information anywhere other than the client log, but that's not where it's pulling it from when running 'q backup path -detail'. In fact, I don't think the client even reports the size other than in the log, does it?
Anyway, I tried this from the server to report the file sizes and file names for every object under /filespace for nodename:
select backups.FILESPACE_NAME, HL_NAME, LL_NAME, ACTUAL_SIZE, BACKUP_DATE, contents.FILE_SIZE from backups, contents where backups.NODE_NAME='nodename' and backups.FILESPACE_NAME='/filespace' and backups.object_id=contents.object_id"
but it just sits there and never prints anything. If I remove the join, and only print information from one table or the other then it's as fast as a speeding car. But even if the above command ever does decide to finally report something, I'm dubious if the 'ACTUAL_SIZE' and/or FILE_SIZE is what I need here. I tried both, hence the join, but when using just ACTUAL_SIZE and no join, the value is always empty for any LL_NAME.
On a related note, why is the client able to report its information so quickly? For example, something like: q backup /path -detail? What tables or columns is it referencing on the server?