On Fri, 2002-10-04 at 13:21, Joe Bacom wrote:
> Thanks Steve; That solves that question. Now for the next one which was my
> real intent (I was just using the wrong terminology).
>
> Setup:
> xfs partition that is 3G in size using 4K block size
> external log on a different partition that is 1G in size, again using 4K
> blocks.
> When I created this partition with the external log, I used the maximum log
> size that mkfs.xfs would allow (-l logdev=/dev/hdc1,size=32768b)
>
> As I said in my earlier message, I make extensive use of extended attributes
> and I need to monitor how much metadata I have stored on disk.
>
> I have gone through the man page and online help of xfs_db, and I have to
> admin some of information is above my knowledge level, but I have not been
> able to discover anything for what I am looking for.
>
> Basically: how much metadata (in bytes, kb, or mb) do I have sitting on the
> disk.
>
> Is there such a command or sequence of commands?
Well, you can count all the data blocks used by files, and then subtract
that from the total blocks used in df output. Not a pleasant prospect.
You can look at the frag and freesp commands in xfs_db, but they do not
do what you want exactly either. The frag command will tell you how many
fragments of directory and attribute metadata you have, but that does
not say how many blocks there actually are.
xfs_db: frag -d (directories, not data)
actual 259, ideal 163, fragmentation factor 37.07%
xfs_db: frag -f (this is data)
actual 3816, ideal 3806, fragmentation factor 0.26%
xfs_db: frag -a
actual 0, ideal 0, fragmentation factor 0.00%
xfs_db: freesp
from to extents blocks pct
1 1 57 57 0.03
2 3 25 62 0.03
4 7 16 78 0.04
8 15 13 144 0.07
16 31 7 170 0.08
32 63 6 334 0.15
64 127 7 613 0.28
128 255 4 763 0.35
256 511 2 697 0.32
512 1023 2 1437 0.66
1024 2047 2 2624 1.20
16384 32767 8 211014 96.80
You can make xfs_db report the type of all blocks in the fs, but it
is somewhat verbose.
block 0 (0/0) type sb
block 1 (0/1) type btino
block 2 (0/2) type btbno
block 3 (0/3) type btcnt
block 4 (0/4) type freelist
block 5 (0/5) type freelist
block 6 (0/6) type freelist
block 7 (0/7) type freelist
block 8 (0/8) type inode
block 9 (0/9) type inode
block 10 (0/10) type inode
block 11 (0/11) type inode
block 12 (0/12) type dir inode 133
block 13 (0/13) type dir inode 147
block 14 (0/14) type inode
block 15 (0/15) type inode
Steve
>
> Thanks;
>
> Joe
>
> On Friday 04 October 2002 11:49 am, Steve Lord wrote:
> > On Fri, 2002-10-04 at 07:56, Joe Bacom wrote:
> > > Hi Folks;
> > >
> > > Hopefully this is an easy question. I would like to know how to
> > > determine the amount of usage / free space that is left in the journal.
> > > I have several filesytems that make heavy use of extended attributes, so
> > > I would like to monitor the journal space to ensure that I don't try to
> > > overfill it.
> >
> > Sending this out since folks are getting confused....
> >
> > The xfs journal (or log, it is called log in the code), is basically
> > a circular on disk buffer. Metadata changes are recorded into the log,
> > and subsequently the real metadata is flushed to disk. The benefits of
> > having a log is we write all the changes which make the filesystem
> > move from one consistent state to another out into the log in one
> > go rather than having to sync up several writes to different parts
> > of the disk. Those writes out to the real metadata happen later, but
> > we do not care at all about the order they happen in.
> >
> > So we perform some transactions, these are written to the log, and
> > our location in the log keeps moving, eventually wrapping around.
> > Normally before we wrap the metadata modified in a transaction has
> > been flushed to disk, so we can just reuse the space. If we are
> > modifying the filesystem faster than metadata can be flushed to
> > disk then new operations which need log space have to force the
> > old metadata out to disk first.
> >
> > So you cannot 'run out' of log space, but you can get into the
> > mode we call tail pushing where the head of the log is always
> > bumping into the tail.
> >
> > Steve
--
Steve Lord voice: +1-651-683-3511
Principal Engineer, Filesystem Software email: lord@xxxxxxx
|