Thanks Steve; That solves that question. Now for the next one which was my
real intent (I was just using the wrong terminology).
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
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
Is there such a command or sequence of commands?
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.