From: Just Marc <marc@corky.net>
To: xfs@oss.sgi.com
Subject: xfs_fsr, performance related tweaks
Date: Thu, 28 Jun 2007 13:47:49 +0100 [thread overview]
Message-ID: <4683ADF5.9050901@corky.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]
Hi,
I'm using fsr extensively.
I noticed two things:
1. in xfs_fsr.c:
if (fsx.fsx_xflags & XFS_XFLAG_NODEFRAG) {
if (vflag)
fsrprintf(_("%s: marked as don't defrag, ignoring\n"),
fname);
return(0);
}
This check should be moved above the code that performs a stat on the
file, to become the first check, this will help reduce redundant stat
calls for heavily defragged fileystems. A simple patch is attached for
that.
2. Files for which 'No improvement will be made' should also be marked
as no-defrag, this will avoid a ton of extra work in the future. In my
particular use case I have many hundreds of thousands of files on each
volume (xfs_fsr runs in a never ending-loop as new files are constantly
being added) and once the file is written to disk it is never changed
again until deletion. Optionally do this only when a special parameter
is passed to fsr at command line? (that is, if you think this is not
appropriate for all scenarios).
I tried to accomplish this but it proved more difficult than I thought.
While digging around in the fsr code, I didn't find out how fsr marks
the file as no-defrag, I'm guessing this is done in kernel code via the
ioctl that swaps the extents (xfs_swapext) ... Is that correct?
I looked at how the 'io' utility marks files as no-defrag; it calls
xfsctl(path, fd, XFS_IOC_FSSETXATTR, &attr); -- this requires a path,
which is not available to me when fsr is run in its default mode which
traverses all xfs filesystems rather than gets to run on a single file.
Is there a way to extract the path in this case? Or possibly use another
way to mark the inode as no-defrag without having to need the path --
just fd? Of course this can be done by an external script which parses
the output of xfs_fsr for these inodes, looks them up and marks them as
such, but that's pretty messy and very inefficient. I'd really like to
do this as cleanly and efficiently as possible.
I would appreciate any feedback you have on this. Please CC me as I'm
not on this list.
Thanks!
[-- Attachment #2: xfs_fsr.diff --]
[-- Type: text/plain, Size: 1370 bytes --]
--- xfs_fsr.c 2007-06-28 13:23:58.745778214 +0100
+++ xfs_fsr.c.orig 2007-06-28 07:40:42.572069164 +0100
@@ -904,6 +904,20 @@
}
}
+ /* Check if there is room to copy the file */
+ if ( statvfs64( (fsname == NULL ? fname : fsname), &vfss) < 0) {
+ fsrprintf(_("unable to get fs stat on %s: %s\n"),
+ fname, strerror(errno));
+ return (-1);
+ }
+ bsize = vfss.f_frsize ? vfss.f_frsize : vfss.f_bsize;
+
+ if (statp->bs_size > ((vfss.f_bfree * bsize) - minimumfree)) {
+ fsrprintf(_("insufficient freespace for: %s: "
+ "size=%lld: ignoring\n"), fname, statp->bs_size);
+ return 1;
+ }
+
if ((ioctl(fd, XFS_IOC_FSGETXATTR, &fsx)) < 0) {
fsrprintf(_("failed to get inode attrs: %s\n"), fname);
return(-1);
@@ -937,20 +951,6 @@
return -1;
}
- /* Check if there is room to copy the file */
- if ( statvfs64( (fsname == NULL ? fname : fsname), &vfss) < 0) {
- fsrprintf(_("unable to get fs stat on %s: %s\n"),
- fname, strerror(errno));
- return (-1);
- }
- bsize = vfss.f_frsize ? vfss.f_frsize : vfss.f_bsize;
-
- if (statp->bs_size > ((vfss.f_bfree * bsize) - minimumfree)) {
- fsrprintf(_("insufficient freespace for: %s: "
- "size=%lld: ignoring\n"), fname, statp->bs_size);
- return 1;
- }
-
/*
* Previously the code forked here, & the child changed it's uid to
* that of the file's owner and then called packfile(), to keep
next reply other threads:[~2007-06-28 13:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-28 12:47 Just Marc [this message]
2007-06-29 0:12 ` xfs_fsr, performance related tweaks Nathan Scott
2007-06-29 6:31 ` Just Marc
2007-06-29 8:13 ` Andi Kleen
2007-06-29 8:23 ` Just Marc
2007-06-29 8:58 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2007-06-28 12:47 Just Marc
2007-06-28 20:38 ` Eric Sandeen
2007-06-29 0:52 ` Andi Kleen
2007-06-29 6:21 ` Just Marc
2007-06-29 6:41 ` Barry Naujok
2007-06-29 6:41 ` Just Marc
2007-06-29 7:08 ` David Chinner
2007-06-29 7:16 ` Just Marc
2007-06-29 7:33 ` Nathan Scott
2007-06-29 7:41 ` David Chinner
2007-06-29 7:39 ` Just Marc
2007-06-30 17:17 ` Eric Sandeen
2007-07-01 22:43 ` David Chinner
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=4683ADF5.9050901@corky.net \
--to=marc@corky.net \
--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