Skip to contentSkip to conversation

Restore ihashsize mount option as deprecated

PATCH In review David Chinner 4 participants 5 messages Aug 9, 2007 – Sep 23, 2007 2 messages not in the archive

Subsystems (2)
Documentation XFS filesystem
lore
Share & tools
lore

David Chinner

author
#0 lore raw

PATCH 1/1 Restore ihashsize mount option as deprecated

The ihashsize option should remain so that filesystems with this set don't fail to mount. Ignore the mount option value and issue a deprecation warning to syslog.

Update the ihashsize mount option documentation to indicate this behaviour. Update the ikeep/noikeep mount option documentation while we are there.

Signed-off-by Dave Chinner <[email protected]>
---
 Documentation/filesystems/xfs.txt |   14 ++++++--------
 fs/xfs/xfs_vfsops.c               |    3 +++
 2 files changed, 9 insertions(+), 8 deletions(-)
fs/xfs/xfs_vfsops.c +3 -0
Index: 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c
===================================================================
@@ -1883,6 +1883,9 @@ xfs_parseargs(
 			args->flags &= ~XFSMNT_ATTR2;
 		} else if (!strcmp(this_char, MNTOPT_FILESTREAM)) {
 			args->flags2 |= XFSMNT2_FILESTREAMS;
+		} else if (!strcmp(this_char, "ihashsize")) {
+			cmn_err(CE_WARN,
+	"XFS: ihashsize no longer used, option is deprecated.");
 		} else if (!strcmp(this_char, "osyncisdsync")) {
 			/* no-op, this is now the default */
 			cmn_err(CE_WARN,
Documentation/filesystems/xfs.txt +6 -8
Index: 2.6.x-xfs-new/Documentation/filesystems/xfs.txt
===================================================================
@@ -52,16 +52,14 @@ When mounting an XFS filesystem, the fol
 	and also gets the setgid bit set if it is a directory itself.
 
   ihashsize=value
-	Sets the number of hash buckets available for hashing the
-	in-memory inodes of the specified mount point.  If a value
-	of zero is used, the value selected by the default algorithm
-	will be displayed in /proc/mounts.
+	In memory inode hashes have been removed, so this option has
+	no function as of August 2007. Option is deprecated.
 
   ikeep/noikeep
-	When inode clusters are emptied of inodes, keep them around
-	on the disk (ikeep) - this is the traditional XFS behaviour
-	and is still the default for now.  Using the noikeep option,
-	inode clusters are returned to the free space pool.
+	When ikeep is specified, XFS does not delete empty inode clusters
+	and keeps them around on disk. ikeep is the traditional XFS
+	behaviour. When noikeep is specified, empty inode clusters
+	are returned to the free space pool. The default is noikeep.
 
   inode64
 	Indicates that XFS is allowed to create inodes at any location

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#2 lore raw
Quoted 6 lines · Eric Sandeen
Quoted 4 lines · David Chinner

The ihashsize option should remain so that filesystems with this set don't fail to mount. Ignore the mount option value and issue a deprecation warning to syslog.

Quoted 6 lines
Quoted 5 lines

Update the ihashsize mount option documentation to indicate this behaviour. Update the ikeep/noikeep mount option documentation while we are there.

Hm, but shouldn't some of these mount struct items go too, now?

Yes. I thought I killed them - must have missed them in some of the patch juggling I had to do at one point.

Quoted 9 lines

(I may go looking for more unused struct members for fun if I have time...)

-------------

Remove unused xfs_mount and xfs_mount_args structure members post radix-tree conversion.

Signed-off-by Eric Sandeen <[email protected]>

Looks ok to me...

Cheers,

Dave.

Signature · 3 lines
Dave Chinner
Principal Engineer
SGI Australian Software Group
#3 lore raw

Did anyone but Dave get Eric's original message? It seems to not have made it to the list.

A message that is not in the archive (sent off-list or not yet received): [email protected]

#5 lore raw
Quoted 9 lines · Eric Sandeen
Quoted 3 lines · Christoph Hellwig

Did anyone but Dave get Eric's original message? It seems to not have made it to the list.

No, it was yet another lost email on oss. I guess the xfs-dev list got it.

Quoted 1 line

From a fairly quick look at logs I have no idea what happened... but

this is clearly a problem that must be solved one way or another.

Have we (or can we) agree on a new list handler? The current mechanism has trouble allowing new subscribers and now we see it's loosing mail too. Let's get this fixed and move on. Who owns this on oss? If nobody, then I'll organize it, but first we need consensus on a replacement.

Thanks

Signature · 4 lines
 Mark Goodwin                                  [email protected]
 Engineering Manager for XFS and PCP    Phone: +61-3-99631937
 SGI Australian Software Group           Cell: +61-4-18969583
-------------------------------------------------------------
#6 lore raw
Quoted 6 lines · Mark Goodwin
Quoted 4 lines · Eric Sandeen
Quoted 3 lines · Christoph Hellwig

Did anyone but Dave get Eric's original message? It seems to not have made it to the list.

Quoted 7 lines
Quoted 4 lines

No, it was yet another lost email on oss. I guess the xfs-dev list got it.

Quoted 1 line

From a fairly quick look at logs I have no idea what happened... but

this is clearly a problem that must be solved one way or another.

Have we (or can we) agree on a new list handler? The current mechanism has trouble allowing new subscribers

That appeared to be spamfilter misfires.

Quoted 2 lines

and now we see it's loosing mail
too.

Not sure anyone has gotten to the bottom of this new problem.

-Eric

Quoted 5 lines

Let's get this fixed and move on. Who owns this on oss? If nobody, then I'll organize it, but first we need consensus on a replacement.

Thanks