Get information of inode on FreeBSD

G

guixingyi

I know that there is one command which is istat on AIX to get inode information, does anyone know is there any similar tool on FreeBSD, seems no info found via google.

appreciate!

:)


Kevin Gui
 
Don't know what exactly istat does on AIX or what particluar information are you interested in, but we have stat(1) command and stat(2); please check their man pages, they contain links to other similar tools.
 
A combination of stat and fsdb (if you're on UFS) seems like it should be able to do everything istat does; for the most common case stat alone (perhaps with the -x flag, to get an output format close to what istat uses) looks like it'd be sufficient.
 
The only information I really cared about was inode usage which is available via df:
Code: 
$ df -i /
Filesystem    1K-blocks   Used   Avail Capacity iused  ifree %iused  Mounted on
/dev/twed0s1a   2026030 584112 1279836    31%    2751 279871    1%   /
 
For comparison, here's the commands and results from the AIX page:
Code: 
> istat /usr/bin/ksh
Inode 10360 on device 10/6    File Protection: r-xr-xr-x
Owner: 2(bin)     Group: 2(bin)
Link count: 2     Length 372298 bytes

Last updated:  Wed May 13 14:08:13 1992
Last modified: Wed May 13 13:57:00 

>istat 10360 /dev/hd2
Inode 10360 on device 10/6    File Protection: r-xr-xr-x
Owner: 2(bin)     Group: 2(bin)
Link count: 2     Length 372298 bytes

Last updated:  Wed May 13 14:08:13 1992
Last modified: Wed May 13 13:57:00 
Block pointers (hexadecimal):
2a9a   2a9b   2a9c   2a9d   2a9e   2a9f   2aa0   2aa1

And here's the same information on FreeBSD:
Code: 
> stat -x /bin/sh
  File: "/bin/sh"
  Size: 112288       FileType: Regular File
  Mode: (0555/-r-xr-xr-x)         Uid: (    0/    root)  Gid: (    0/   wheel)
Device: 0,91   Inode: 49057    Links: 1
Access: Fri Nov 28 17:50:03 2008
Modify: Tue Jun  3 16:13:27 2008
Change: Tue Jun  3 16:13:27 2008


# fsdb -r /dev/ad14s1a
(...)
fsdb (inum: 2)> inode 49057
current inode: regular file
I=49057 MODE=100555 SIZE=112288
        BTIME=Jun  3 16:13:27 2008 [0 nsec]
        MTIME=Jun  3 16:13:27 2008 [0 nsec]
        CTIME=Jun  3 16:13:27 2008 [0 nsec]
        ATIME=Nov 28 17:50:03 2008 [0 nsec]
OWNER=root GRP=wheel LINKCNT=1 FLAGS=0 BLKCNT=dc GEN=2d96bb57
fsdb (inum: 49057)> blocks
Blocks for inode 49057:
Direct blocks:
194536, 194544, 194552, 194560, 194568, 194576, 194632 (7 frags)
fsdb (inum: 49057)> ^D
c2d#

Of course, fsdb isn't the ideal tool for this.
One possible way to get the normal stat information for an inode (but not the block numbers) is to do
Code: 
> find -x / -inum 49057 -exec stat -x {} \;
  File: "/bin/sh"
  Size: 112288       FileType: Regular File
  Mode: (0555/-r-xr-xr-x)         Uid: (    0/    root)  Gid: (    0/   wheel)
Device: 0,91   Inode: 49057    Links: 1
Access: Fri Nov 28 18:05:57 2008
Modify: Tue Jun  3 16:13:27 2008
Change: Tue Jun  3 16:13:27 2008

(And a whole slew of Permission Denied warnings.)
 
I needed the same info, thanks for the answer

Turns out I needed the same info (given an inode number and a filesystem, how do I get a stat struct). I've built a file tree walker that accumulates statistics of the files along the way. Since I'm already doing the work of walking the filesystem and have the dev_t and ino_t of each file I care about, it seems silly to assemble a pathname to hand to stat() so it, too, can walk the filesystem and get the same dev_t/ino_t I already have so it can pull the data from the on-disk inode table or in-core inode cache.

Looks like FreeBSD doesn't have such a call (like AIX's istat()) that takes a dev_t/ino_t pair and returns a struct stat. Bummer.
 
Mel_Flynn said:
And you're not using fts(3) because?
Click to expand...
... because I'm using nftw(3). Nonetheless, my sadness remains; nftw etc. have no way to do the equivalent of istat(), so they, too, wind up walking lots of paths for stat() unnecessarily. The tool I've built winds up walking several million files across 400+GB of storage. Performance actually matters, and reducing the number of times through the pathname parsing code in the kernel would actually help.
 
You must log in or register to reply here.
Back
Top