That information does not exist in the directory metadata so I would not expect to find it via the RAN API.  InsightIQ reports on directory sizes based on the FSA job.  Bottom line, you have to walk the tree to get the size.

While you could treewalk via the RAN API, I don't think you would want to. Based on my testing, it is much slower than NFS or SMB access.

It would be a very nice feature to add to the metadata. This would probably also make the FSA job much faster. FSA has been running for 10.3w in our system. We have a huge number of small files and new files are constantly added/removed. This seems to kill the FSA job, hence, we have not had one successful run since we installed the cluster.

There are reporting (non-enforced) quotas to begin which... What you are asking for would be quotas of steroids in the sense that each file write would have to be accounted for in all enclosing directories up to /ifs. Now that would kill performance unless one day this would be done just in RAM or better some magnificent persistent bit-keepers with RAM-like speed.

As for your FSA job,  do you have SSD for metadata read acceleration? Our cluster scans 200 Mio files in 6-7 hours + another few hours for building the index. And it's just three 200GB SSDs that hold all the metadata...

Cheers

-- Peter

Yes, we have both SSD og metadata accelleration activated. We only have 6TB disks. We have a mixed setup of s200 and nl400 nodes. Currently we have around 650m files. These are constantly renewed. I do see your point regarding the metadata. The scan takes around 1 week and the remaining time is the index build.

I've got around 1.5B objects in my mixed S/NL cluster with a lot of churn and the metadata on SSDs (except the 6TB NL410s, but that's another story). My fsanalyze jobs typically run phase 1 in about a day, then sit on phase 2 for a couple of days. Which version of OneFS are you on? And how many nodes total?

Thanks, but your config isn't very clear to me. With 6TB drives AFAIK the only acceleration mechanism is the L3 metadata cache, and it seems pretty tough to confirm at a certain point in time wether it got fully warmed up without overflowing. Need to watch the L3 metadata start/hit/miss rates continuously.

Cheers

-- Peter

With 1.5B objects, it's a pretty wide range of static vs changing, but there is a fairly high rate of change. You should have plenty of CPU (within the range of crappy CPUs Isilon uses) to handle this, so you're probably running into the whole phase 2 only runs on one core of one node problem. I don't know if that has ever really been resolved.

I am running 18 x S200, 8 x NL400. OneFS is 7.2.0.2. Are your files static or are they changing? I think I will give support a call regarding this. They did look at the job earlier, but that never fixed the issue.

This is a great discussion.  Thanks everyone for chiming in.

To answer the original question asked by spengler, the OneFS API (through RAN) does not currently provide that feature.  There are other ways to get at that information.  InsightIQ can, but it is dependent on the FSA job completing. If the FSA job isn't completing in a timely manner, InsightIQ would not be able to use that up-to-date info.

Isilon Product Management and Engineering teams have been focused heavily in this area.  Definitely stay tuned for announcements to the improvements in this area.  (This is all I am allowed to say on a public forum).

If your FSA job is completing, you could use InsightIQ's graphical interface to get at the directory size.  Or alternatively, you could use the iiq_data_export utility on the IIQ instance to export that information in an automated fashion (use case is if you are trying to do so with many directories).

See this thread -- Exporting InsightIQ data -- search for the string "iiq_data_export".

Hope this helps.