Re: calc directory size on IFS

Good point - I have a 12-byte file on a system that has 8KB allocation. Everything on i is constructed out of segments of pages - 4KB to my understanding, so  I'm a little surprised at the 8KB here.

The screen you get with EDTF does show allocated size - and 6 on a directory  gives something like this - I had put 6 on the Opt next to VHAMBERG.

Directory: /home
 Position to :                Record :      97 of
 New File :
 2=Edit  4=Delete File   5=Display  6=Path Size   9=Recursive Delete

Opt Name                 Size       Owner        Changed Used            CCSID or Symbolic Link
    VHAMBERG               19,780K  VHAMBERG     03/14/22 07:54 03/26/22 10:16     SUBDIRECTORIES = 19, FILES = 25

I think this does not count files within the subdirectories, reason is, the IFS ACS tool shows more folders and files than this - 31 files, 27 folders in the properties. I think properties there for a folder give data size, not allocated. For a single file it gives both.

There is an IFS stat API, I think, that has all this - perhaps used in the SQL service.

Many options - not all as helpful for the task the OP presented. I find myself using most of them at one time or another.

Cheers
Vern

On 3/25/2022 10:33 PM, Roger Harman wrote:

The other benefit of the service is getting allocated size vs. actual file size. A jillion little files can take up a lot of (allocated) disk.



-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Vern Hamberg via MIDRANGE-L
Sent: Friday, March 25, 2022 7:18 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Cc: Vern Hamberg <vhamberg@xxxxxxxxxxxxxxx>
Subject: Re: calc directory size on IFS

Should be able to get the count there, as well. OP seems to know that
already, but......

Vern

On 3/25/2022 9:04 PM, Jack Woehr via MIDRANGE-L wrote:

*SELECT SUM(ALLOCATED_SIZE) FROM TABLE (
QSYS2.IFS_OBJECT_STATISTICS(START_PATH_NAME => '/home/jwoehr',
SUBTREE_DIRECTORIES => 'YES')*
* );*

This yields

*00001*
*--------*
*13276467200*

On Fri, Mar 25, 2022 at 7:42 PM Vern Hamberg via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

The service is probably the best way to go.