BackupPC-users

Re: [BackupPC-users] Best FS for BackupPC

2011-05-26 10:56:03
Subject: Re: [BackupPC-users] Best FS for BackupPC
From: Holger Parplies <wbppc AT parplies DOT de>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Thu, 26 May 2011 16:55:19 +0200
Hi,

Carl Wilhelm Soderstrom wrote on 2011-05-26 06:05:48 -0500 [Re: 
[BackupPC-users] Best FS for BackupPC]:
> On 05/26 12:20 , Adam Goryachev wrote:
> > BTW, specifically related to backuppc, many years ago, reiserfsck was
> > perfect as it doesn't have any concept or limit on 'inodes'... Same for
> > mail and news (nntp) servers. Do XFS/JFS have this feature? I'll look
> > into these things another day, when I have some time :)
> 
> There are indeed 'inodes' listed in the 'df -i' output of XFS filesystems.
> However, I've never heard of anyone hitting the inode limit on XFS, unlike
> ext3.

of course XFS *has* inodes, and I wondered about the 'df -i' output, too, when
I tried it yesterday. I don't remember reiserfs giving any meaningful
information for 'df -i' ... nope, '0 0 0 -'. I sincerely hope that XFS doesn't
have *static inode allocation*, meaning I have to choose the number of inodes
at file system creation time and waste any space I reserve for them but do not
turn out to need. That was one main concern when choosing my pool FS.
Actually, mkfs.xfs(8) explains a parameter '-i maxpct=<value>':

        This  specifies  the  maximum percentage of space in
        the filesystem that can be allocated to inodes.  The
        default  value  is 25% for filesystems under 1TB, 5%
        for filesystems under 50TB and  1%  for  filesystems
        over 50TB.

The further explanation says this is achieved by the data block allocator
avoiding lower blocks, which are needed for obtaining 32-bit inode numbers.
It leaves two questions unanswered (to me, at least):

1.) Is this a hard limit, or will inodes continue to be allocated in excess
    of this percentage, (a) if more space happens to be free in the "lower
    blocks", or (b) generating inode numbers exceeding 32 bits, provided the
    kernel supports them (probably only 64-bit kernels)?
2.) Will the data block allocator use these blocks up once no other blocks
    are available any more, or is your XFS full, even though you've got
    another 249GB(!) free on your 1TB FS, that are reserved for inodes?

The answer to (2) is most likely "the data block allocator will use them",
because the man page goes on:

        Setting the value to 0 means that essentially all of
        the filesystem can become inode blocks,  subject  to
        inode32 restrictions.

(however, it could be a special case for the value "0"). In fact, the very
concept of allocating inodes rather than reserving fixed blocks for them
strongly suggests some flexibility in deciding how much space will be used
for them and how much for data.

In any case, the default percentage seems to allow for far more inodes than
with ext[23], which might explain why you hit the boundary later (if at all).

Regards,
Holger

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/