Subject: Re: Aliases: Are alternate filesystems worth trying?
From: Mac Conin (mconin@euc.de)
Date: Thu Jun 07 2001 - 03:34:41 EDT
We' re running 1.56 on suse 7.1 (kernel 2.4) and a raid system of ~200GB
df -i shows
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 102592 32103 70489 32% /
/dev/sda3 4294967295 0 4294967295 0% /data1
/dev/sdb1 4294967295 0 4294967295 0% /data2
and it works, (with little backdraws resulting from a presumed misconf.
by mayself)
Richard Goldman wrote:
>
> Well, gotta retract a few things here, sorry folks:
>
> If an XFS volume is created as I've suggested (in this case on a 36GB raid 5 md), the "df -i" command reports that I have 4,480,192 inodes to play with -- certainly less than the 16,777,216 that can be encoded in an alias.
>
> However, after stress-testing and adding about 100,000 new files and directories to the raid, I have inode numbers higher than 16,777,216, which is not safe. Matthew Geier, I believe, had mentioned that XFS inodes may "encode a disk address..." and not be members of a fixed pool.
>
> So, off to some other filesystem. Any comments on Reiser or ext2 with regards to putting a limit on total inodes (and of course where and inode number won't exceed in value, the total number of inodes)?
>
> By the way... here's how you can see the inode encoding within an alias:
>
> Using Apple's resedit, open the alias resource and look at the six hex digits beginning with position 73. These six digits, when converted to binary (4 bits apiece) and appended to each other, yield the 24 bit binary equivalent of the decimal value of the inode (such as from the "ls -i filename" or "stat filename" commands).
>
> It also appears, at least as of the CVS from the morning of June 6 (PDT), the new mtab stuff isn't having an impact on the encoding.
>
> -- Richard
>
> ---------- Original Message ----------------------------------
> From: "Richard Goldman" <rgml@graphpoint.com>
> Reply-To: <rgml@graphpoint.com>
> Date: Wed, 6 Jun 2001 14:36:26 -0400
>
> >Thank you all so much for the explanations and leads on understanding the issue of aliases/DID's/files/etc.
> >
> >A few notes so far:
> >
> >Linux Kernel-2.4.5-XFS appears to be a stable platform for netatalk. Download the full source tree from SGI's CVS (this will ensure that you're getting the 2.4.5 kernel). Know that this pre-patched XFS-cabable kernel distrib from SGI is missing two key files from linux/drivers/scsi/aic7xxx (Adaptec driver). These files are aic7xxx_reg.h and aic7xxx_seq.h. Find these files from the kernel.org distrib of the stock 2.4.5 -- and only this version, as the Adaptec driver underwent a major patch between the 2..4.4 and 2.4.5 kernels.
> >
> >Remember to compile the utilities as well, and lower your alias/DID problems by lowering your inode count on XFS by creating the filesystem with this command: mkfs.xfs -i -size=2048 /dev/whatever. The the -size subdirective is really asking for a ratio of inodes to to fs blocks. With Linux XFS frozen at 4k blocks, by asking for 2048 bytes here, your telling the system to be made with roughly 2 inodes per block instead of the built-in default of -size=256 giving you 16 inodes per 4k block. That would quickly bust the 16,777,216 inode limit addressable in the 24 inode-dedicated bits in the current alias mapping scheme (which you get when you don't invoke --enable-lastdid in ./configure).
> >
> >I noticed in the CVS this morning that Jeff had added the new configure option on --with-did={last,mtab). The mtab option points to an implementation of Bob Rogers scheme to devote more of the alias address space to inodes (raised to 28 bits? 29 bits? from the current 24).
> >
> >Does anyone know if the implementation is complete, i.e. that the new afpd.mtab file is being read, and this new dev-inode scheme is active and usable if --with-did=mtab is specified?
> >
> >Regards,
> >Richard
> >
> >
-- --schnipp--mit freundlichen grüssen
----------------------------------------------------------- Mac Conin EUC Online Service GmbH Geschäftsführer Taubengasse 9 mconin@euc.de D 50676 Koeln http://www.euc.de HRB Köln 32038 tel : +49-221-923 27 33 fax : +49-221-239 651 ----------------------------------------------------------- EUC sponsort Clean up Cologne - eine Iniative der IHK Köln, der Abfallwirtschaftsbetriebe Köln (AWB) und dem Grünflächenamt der Stadt Köln. http://www.clean-up-cologne.de
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:41 EDT