* free inodes remaining in 1tb
@ 2013-09-26 22:47 Keith Keller
2013-09-26 23:03 ` Carlos Maiolino
2013-09-27 1:08 ` Dave Chinner
0 siblings, 2 replies; 6+ messages in thread
From: Keith Keller @ 2013-09-26 22:47 UTC (permalink / raw)
To: linux-xfs
Hi all,
I "recently" (a few months ago) came across the inode64 entries in the
XFS FAQ. Unfortunately, I have a filesystem not mounted with inode64,
and I would like to know how many more inodes I can create in the
first 1TB before I run out, so that I can plan for a migration to
inode64 (if it's very few, I would make it a high priority; if not, it
can be done in a few weeks instead, for example). Is there an easy
way (or even a hard way) to query the filesystem for this information?
I also wanted to ask about the FAQ that says you can switch back from
inode64 to inode32. How does that work if an inode is created past the
1TB mark? How would the kernel know how to find an inode64 inode that
was created beyond the 1TB mark if the filesystem is subsequentely
mounted without inode64?
Thanks,
--keith
--
kkeller@wombat.san-francisco.ca.us
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: free inodes remaining in 1tb
2013-09-26 22:47 free inodes remaining in 1tb Keith Keller
@ 2013-09-26 23:03 ` Carlos Maiolino
2013-09-27 1:08 ` Dave Chinner
1 sibling, 0 replies; 6+ messages in thread
From: Carlos Maiolino @ 2013-09-26 23:03 UTC (permalink / raw)
To: xfs, linux-xfs
On Thu, Sep 26, 2013 at 03:47:00PM -0700, Keith Keller wrote:
> Hi all,
>
> I "recently" (a few months ago) came across the inode64 entries in the
> XFS FAQ. Unfortunately, I have a filesystem not mounted with inode64,
> and I would like to know how many more inodes I can create in the
> first 1TB before I run out,
The maximum amount of the filesystem that can be used by inodes (by default)
are:
25% for filesystems under 1TB, 5% for filesystems under 50TB and 1% for
filesystems over 50TB.
>so that I can plan for a migration to
> inode64 (if it's very few, I would make it a high priority; if not, it
> can be done in a few weeks instead, for example). Is there an easy
> way (or even a hard way) to query the filesystem for this information?
>
inode64 is a remountable option now (if you're using a relatively recent
kernel), so you don't need to umount and remount it.
> I also wanted to ask about the FAQ that says you can switch back from
> inode64 to inode32. How does that work if an inode is created past the
> 1TB mark? How would the kernel know how to find an inode64 inode that
> was created beyond the 1TB mark if the filesystem is subsequentely
> mounted without inode64?
>
inode32 option only dictates where the filesystem will create next inodes, not
where it will search for already created inodes.
bear in mind though that are some applications that can't read 64bit inodes.
> Thanks,
>
> --keith
>
> --
> kkeller@wombat.san-francisco.ca.us
>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
--
Carlos
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: free inodes remaining in 1tb
2013-09-26 22:47 free inodes remaining in 1tb Keith Keller
2013-09-26 23:03 ` Carlos Maiolino
@ 2013-09-27 1:08 ` Dave Chinner
2013-09-27 8:18 ` Keith Keller
1 sibling, 1 reply; 6+ messages in thread
From: Dave Chinner @ 2013-09-27 1:08 UTC (permalink / raw)
To: Keith Keller; +Cc: linux-xfs
On Thu, Sep 26, 2013 at 03:47:00PM -0700, Keith Keller wrote:
> Hi all,
>
> I "recently" (a few months ago) came across the inode64 entries in the
> XFS FAQ. Unfortunately, I have a filesystem not mounted with inode64,
> and I would like to know how many more inodes I can create in the
> first 1TB before I run out,
Depends on how much other data is allocated in the first TB
(occurs when you fill the space above 1TB completely), the
size of the allocation groups (how much of the first TB canbe used
for inodes), how many inodes and other metadata you've already
allocated, etc.
> so that I can plan for a migration to
> inode64 (if it's very few, I would make it a high priority; if not, it
> can be done in a few weeks instead, for example). Is there an easy
> way (or even a hard way) to query the filesystem for this information?
Only a hard way - using xfs_db to look at on-disk structures and
inferring the state from there...
> I also wanted to ask about the FAQ that says you can switch back from
> inode64 to inode32. How does that work if an inode is created past the
> 1TB mark?
Depends on how old your kernel is. Access to 64 bit inodes when
mounting with inode32 only came along in 2010:
commit fb3b504adeee942e55393396fea8fdf406acf037
Author: Christoph Hellwig <hch@infradead.org>
Date: Fri May 28 19:03:10 2010 +0000
xfs: fix access to upper inodes without inode64
If a filesystem is mounted without the inode64 mount option we
should still be able to access inodes not fitting into 32 bits, just
not created new ones. For this to work we need to make sure the
inode cache radix tree is initialized for all allocation groups, not
just those we plan to allocate inodes from. This patch makes sure
we initialize the inode cache radix tree for all allocation groups,
and also cleans xfs_initialize_perag up a bit to separate the
inode32 logical from the general perag structure setup.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
So if you have an old kernel (older than 2.6.35), you won't be able
to access 64 bit inodes at all if you mount with inode32. Anything
more recent than that will work just fine.
> How would the kernel know how to find an inode64 inode that
> was created beyond the 1TB mark if the filesystem is subsequentely
> mounted without inode64?
The inode number is an encoding of the physical location of the inod
inthe filesystem. Hence the kernel code can always find the inode
location - it just may not be able to do anything with it because
the caches on old kernels can't index them...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: free inodes remaining in 1tb
2013-09-27 1:08 ` Dave Chinner
@ 2013-09-27 8:18 ` Keith Keller
2013-09-27 9:26 ` Stefan Ring
2013-09-27 12:47 ` Carlos Maiolino
0 siblings, 2 replies; 6+ messages in thread
From: Keith Keller @ 2013-09-27 8:18 UTC (permalink / raw)
To: linux-xfs
Thank you both Dave and Carlos for your replies. My response inline.
On Fri, Sep 27, 2013 at 11:08:47AM +1000, Dave Chinner wrote:
> On Thu, Sep 26, 2013 at 03:47:00PM -0700, Keith Keller wrote:
>
> > so that I can plan for a migration to
> > inode64 (if it's very few, I would make it a high priority; if not, it
> > can be done in a few weeks instead, for example). Is there an easy
> > way (or even a hard way) to query the filesystem for this information?
>
> Only a hard way - using xfs_db to look at on-disk structures and
> inferring the state from there...
That's what I was afraid of. :)
> So if you have an old kernel (older than 2.6.35), you won't be able
> to access 64 bit inodes at all if you mount with inode32. Anything
> more recent than that will work just fine.
I am currently using a stock CentOS kernel, 2.6.32-358.14.1.el6.x86_64.
I'd have to check the changelogs to see if that kernel has the patch
in question, which I will do tomorrow. I have another machine on
kernel-ml which I'm trying out now, and may simply move the original
machine to it as well.
> The inode number is an encoding of the physical location of the inod
> inthe filesystem. Hence the kernel code can always find the inode
> location - it just may not be able to do anything with it because
> the caches on old kernels can't index them...
Great, thanks, that's really helpful.
On 2013-09-26, Carlos Maiolino <cmaiolino@redhat.com> wrote:
> bear in mind though that are some applications that can't read 64bit
> inodes.
I know that NFS has some issues (documented in the XFS FAQ). Do you
know offhand of any other examples?
--keith
--
kkeller@wombat.san-francisco.ca.us
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: free inodes remaining in 1tb
2013-09-27 8:18 ` Keith Keller
@ 2013-09-27 9:26 ` Stefan Ring
2013-09-27 12:47 ` Carlos Maiolino
1 sibling, 0 replies; 6+ messages in thread
From: Stefan Ring @ 2013-09-27 9:26 UTC (permalink / raw)
To: Keith Keller; +Cc: linux-xfs
> I am currently using a stock CentOS kernel, 2.6.32-358.14.1.el6.x86_64.
> I'd have to check the changelogs to see if that kernel has the patch
> in question, which I will do tomorrow.
The cited patch seems to have appeared in 2.6.32-220.el6.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: free inodes remaining in 1tb
2013-09-27 8:18 ` Keith Keller
2013-09-27 9:26 ` Stefan Ring
@ 2013-09-27 12:47 ` Carlos Maiolino
1 sibling, 0 replies; 6+ messages in thread
From: Carlos Maiolino @ 2013-09-27 12:47 UTC (permalink / raw)
To: xfs
Hi,
> On 2013-09-26, Carlos Maiolino <cmaiolino@redhat.com> wrote:
> > bear in mind though that are some applications that can't read 64bit
> > inodes.
>
> I know that NFS has some issues (documented in the XFS FAQ). Do you
> know offhand of any other examples?
>
My apologies, I'm not a heavy user of applications that handle file's inodes.
What I can tell you is that any application that might need to handle file's
inodes would be worth to check if they can handle 64bit inodes, for example,
some backup applications use to handle inodes for some reason (read it as 'I
have no idea how these backup apps works' :), and I've seen some reports about
problems with backup applications for this reason some time ago, but can't
really point you out anything specific.
--
Carlos
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-09-27 12:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-26 22:47 free inodes remaining in 1tb Keith Keller
2013-09-26 23:03 ` Carlos Maiolino
2013-09-27 1:08 ` Dave Chinner
2013-09-27 8:18 ` Keith Keller
2013-09-27 9:26 ` Stefan Ring
2013-09-27 12:47 ` Carlos Maiolino
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox