From: Christoph Hellwig <hch@infradead.org>
To: Bernard Chan <bernard@goanimate.com>
Cc: xfs@oss.sgi.com
Subject: Re: ENOSPC and filesystem shutdowns
Date: Mon, 5 Sep 2011 03:47:34 -0400 [thread overview]
Message-ID: <20110905074734.GA18504@infradead.org> (raw)
In-Reply-To: <CAKxAxjFgBd0Vt02m7FJKq_ZWNBBJ5B=N4u7kS69FKtOKT4UowA@mail.gmail.com>
On Sun, Sep 04, 2011 at 02:09:49PM +0800, Bernard Chan wrote:
> We have an XFS filesystem (on LVM, probably doesn't matter anyway) that is
> 4TB running on CentOS kernel 2.6.21.7,
Isn't Centos based on RHEL and thus running either 2.6.9, 2.6.18 or
2.6.32-ish kernels?
> We searched and found this list, and a few patches around kernel
> 2.6.26-2.6.27 that seem to match our scenario. We were able to log the
> specific mkdir command that failed and confirmed it consistently fails that
> way that gives "no space left on device", while we did not reproduce the
> same issue mkdir in other directories with large inode numbers. We haven't
> tried patching or upgrading the kernel yet, but we will do that later.
>
> As the root cause of that patch points to a bug triggered by ENOSPC, we
> checked the inode numbers created for some directories and files with "ls
> -li" and some of them are pretty close to 2^32.
>
> So, we would like to ascertain if that is the cause for ENOSPC in our case,
> and does that mean 32-bit inodes are no longer adequate for us and we should
> switch to 64-bit inodes? Will switching it avoid this kind of shutdowns with
> successful writes in the future?
>
> And is it true that we don't need a 64-bit OS for 64-bit inodes? How can we
> tell if our system supports 64-bit inodes?
It doesn't. On Linux XFS only supports inode64 on 32-bit systems since
Linux 3.0.
> Finally, although we all know that "df -i" is sort of nonsense on XFS, how
> can we get the output of 5% inode while having inode numbers that are close
> to 2^32? So what does that 5% exactly mean, or were I looking at inodes the
> wrong way?
It's based on the available space given that XFS can theoretically use
any inode block for data.
> Thanks in advance for any insights anyone may shed on this one.
I'd move off a 4.5-year old unsupposed kernel. The real RHEL/Centos
kernel have fairly good xfs support these days if you want a backporting
option. Even RHEL5 might have inode64 on 32-bit systems as it has a lot
of XFS updates backport, but in doubt I would recommend to move to
a RHEL6/Centos6 kernel at least.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-09-05 7:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-04 6:09 ENOSPC and filesystem shutdowns Bernard Chan
2011-09-05 7:47 ` Christoph Hellwig [this message]
2011-09-08 11:09 ` Bernard Chan
2011-09-09 7:19 ` Michael Monnerie
2011-09-09 8:00 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110905074734.GA18504@infradead.org \
--to=hch@infradead.org \
--cc=bernard@goanimate.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox