hq ~ # /usr/sbin/xfs_quota -x -c "quota -N -u brian" /home
xfs_quota: cannot find mount point for path `/share/systems': Success
xfs_quota: cannot find mount point for path `/share/cs': Success
xfs_quota: cannot find mount point for path `/share/cas': Success
xfs_quota: cannot find mount point for path `/share/cfcp': Success
xfs_quota: cannot find mount point for path `/share/lgs': Success
xfs_quota: cannot find mount point for path `/share/common': Success
xfs_quota: cannot find mount point for path `/share/summer': Success
/dev/mapper/hq-home 3763680 0 0 00 [--------] /home
Why is it complaining about success?
These messages only occurred after upgrading a lenny system to squeeze.
strace shows no errors at this point:
write(2, "xfs_quota: cannot find mount poi"..., 70xfs_quota: cannot find
mount point for path `/share/systems': Success
) = 70
stat64("/share/cs", {st_mode=S_IFDIR|S_ISGID|0755, st_size=118, ...}) = 0
write(2, "xfs_quota: cannot find mount poi"..., 65xfs_quota: cannot find
mount point for path `/share/cs': Success
) = 65
stat64("/share/cas", {st_mode=S_IFDIR|S_ISGID|0775, st_size=117, ...}) = 0
write(2, "xfs_quota: cannot find mount poi"..., 66xfs_quota: cannot find
mount point for path `/share/cas': Success
) = 66
stat64("/share/cfcp", {st_mode=S_IFDIR|S_ISGID|0755, st_size=99, ...}) = 0
write(2, "xfs_quota: cannot find mount poi"..., 67xfs_quota: cannot find
mount point for path `/share/cfcp': Success
) = 67
stat64("/share/lgs", {st_mode=S_IFDIR|S_ISGID|0750, st_size=89, ...}) = 0
write(2, "xfs_quota: cannot find mount poi"..., 66xfs_quota: cannot find
mount point for path `/share/lgs': Success
) = 66
stat64("/share/common", {st_mode=S_IFDIR|S_ISGID|0755, st_size=96, ...}) = 0
write(2, "xfs_quota: cannot find mount poi"..., 69xfs_quota: cannot find
mount point for path `/share/common': Success
) = 69
stat64("/share/summer", {st_mode=S_IFDIR|S_ISGID|0770, st_size=4096, ...})
= 0
write(2, "xfs_quota: cannot find mount poi"..., 69xfs_quota: cannot find
mount point for path `/share/summer': Success
) = 69
Yes, I found the same (IIRC) code. However, strace clearly shows the result of stat64 is 0, and the above is for values less then 0, so this shouldn't happen... Not AFAIK. Has the format or parsing changed? hq ~ # cat /etc/projects 3:/share/systems 4:/share/cs 5:/share/cas 5:/share/cfcp 6:/share/lgs #7:/share/csd 8:/share/common 9:/share/summer
Yes, I found the same (IIRC) code. However, strace clearly shows the result of stat64 is 0, and the above is for values less then 0, so this shouldn't happen... Not AFAIK. Has the format or parsing changed? hq ~ # cat /etc/projects 3:/share/systems 4:/share/cs 5:/share/cas 5:/share/cfcp 6:/share/lgs #7:/share/csd 8:/share/common 9:/share/summer
Hey Brian,
Looks like that would be print out of fs_table_initialise_projects.
40 static int
41 fs_device_number(
42 const char *name,
43 dev_t *devnum)
44 {
45 struct stat64 sbuf;
46
47 if (stat64(name, &sbuf) < 0)
48 return errno;
^^^^^^^^ here?
49 /*
50 * We want to match st_rdev if the path provided is a device
51 * special file. Otherwise we are looking for the the
52 * device id for the containing filesystem, in st_dev.
53 */
54 if (S_ISBLK(sbuf.st_mode) || S_ISCHR(sbuf.st_mode))
55 *devnum = sbuf.st_rdev;
56 else
57 *devnum = sbuf.st_dev;
58
59 return 0;
60 }
Do you have a wonky /etc/projects file or something?
Regards,
Ben
Hey Brian,
Looks like that would be print out of fs_table_initialise_projects.
40 static int
41 fs_device_number(
42 const char *name,
43 dev_t *devnum)
44 {
45 struct stat64 sbuf;
46
47 if (stat64(name, &sbuf) < 0)
48 return errno;
^^^^^^^^ here?
49 /*
50 * We want to match st_rdev if the path provided is a device
51 * special file. Otherwise we are looking for the the
52 * device id for the containing filesystem, in st_dev.
53 */
54 if (S_ISBLK(sbuf.st_mode) || S_ISCHR(sbuf.st_mode))
55 *devnum = sbuf.st_rdev;
56 else
57 *devnum = sbuf.st_dev;
58
59 return 0;
60 }
Do you have a wonky /etc/projects file or something?
Regards,
Ben
Can you test a current upstream version and if it fails post the full strace output? There's been some changes recently for quota iteration bugs that may avoid/fix this issue... Cheers, Dave.
D'oh. I guess that fs_cursor_next_entry is the next candidate:
355 /*
356 * Given a directory, match it up to a filesystem mount point.
357 */
358 static struct fs_path *
359 fs_mount_point_from_path(
360 const char *dir)
361 {
362 fs_cursor_t cursor;
363 fs_path_t *fs;
364 dev_t dev = 0;
365
366 if (fs_device_number(dir, &dev))
367 return NULL;
368
369 fs_cursor_initialise(NULL, FS_MOUNT_POINT, &cursor);
370 while ((fs = fs_cursor_next_entry(&cursor))) {
371 if (fs->fs_datadev == dev)
372 break;
373 }
374 return fs;
375 }
Hmm. There are some recent commits that look related. Commit 36298cced and
19473a2ac. Can you try with this code?
git://oss.sgi.com/xfs/cmds/xfsprogs.git
Nope. Looks ok to me.
Regards,
Ben
Can you test a current upstream version and if it fails post the full strace output? There's been some changes recently for quota iteration bugs that may avoid/fix this issue... Cheers, Dave.
D'oh. I guess that fs_cursor_next_entry is the next candidate:
355 /*
356 * Given a directory, match it up to a filesystem mount point.
357 */
358 static struct fs_path *
359 fs_mount_point_from_path(
360 const char *dir)
361 {
362 fs_cursor_t cursor;
363 fs_path_t *fs;
364 dev_t dev = 0;
365
366 if (fs_device_number(dir, &dev))
367 return NULL;
368
369 fs_cursor_initialise(NULL, FS_MOUNT_POINT, &cursor);
370 while ((fs = fs_cursor_next_entry(&cursor))) {
371 if (fs->fs_datadev == dev)
372 break;
373 }
374 return fs;
375 }
Hmm. There are some recent commits that look related. Commit 36298cced and
19473a2ac. Can you try with this code?
git://oss.sgi.com/xfs/cmds/xfsprogs.git
Nope. Looks ok to me.
Regards,
Ben
No change :-( hq ~ # ~brian/xfsprogs/quota/xfs_quota -x -c "quota -N -u brian" /home xfs_quota: cannot find mount point for path `/share/systems': Success xfs_quota: cannot find mount point for path `/share/cs': Success xfs_quota: cannot find mount point for path `/share/cas': Success xfs_quota: cannot find mount point for path `/share/cfcp': Success xfs_quota: cannot find mount point for path `/share/lgs': Success xfs_quota: cannot find mount point for path `/share/common': Success xfs_quota: cannot find mount point for path `/share/summer': Success /dev/mapper/hq-home 3795788 0 0 00 [--------] /home That is the latest version, 36298ccedf8c8ff28b1c8c6a3a235392c9a28026 from the master branch.
No change :-( hq ~ # ~brian/xfsprogs/quota/xfs_quota -x -c "quota -N -u brian" /home xfs_quota: cannot find mount point for path `/share/systems': Success xfs_quota: cannot find mount point for path `/share/cs': Success xfs_quota: cannot find mount point for path `/share/cas': Success xfs_quota: cannot find mount point for path `/share/cfcp': Success xfs_quota: cannot find mount point for path `/share/lgs': Success xfs_quota: cannot find mount point for path `/share/common': Success xfs_quota: cannot find mount point for path `/share/summer': Success /dev/mapper/hq-home 3795788 0 0 00 [--------] /home That is the latest version, 36298ccedf8c8ff28b1c8c6a3a235392c9a28026 from the master branch.
Full strace output, please. Cheers, Dave.
Full strace output, please. Cheers, Dave.
Attached.
Did my strace output help diagnose this bug? Thanks
No, but it's most likely the same problem as fixed in commit 19473a2ac. Can you add this to quota/quot.c:quot_init(): + quot_cmd.flags = CMD_FLAG_GLOBAL; And see if the problem goes away? Cheers, Dave.
I made this change to the version in Debian squeeze. I didn't see any change in behaviour :-( hq ~ # xfs_quota -x -c "quota -N -u brian" /home xfs_quota: cannot find mount point for path `/share/systems': Success xfs_quota: cannot find mount point for path `/share/cs': Success xfs_quota: cannot find mount point for path `/share/cas': Success xfs_quota: cannot find mount point for path `/share/cfcp': Success xfs_quota: cannot find mount point for path `/share/lgs': Success xfs_quota: cannot find mount point for path `/share/common': Success xfs_quota: cannot find mount point for path `/share/summer': Success /dev/mapper/hq-home 3800752 0 0 00 [--------] /home Also tried the same patch against the latest git version, and got the same problem.
Which tells me exactly what is happening. The project quotas are not on the filesystem you directed the the quota command at, and xfs_quota is telling you that it can't find the mount point for the configured project quotas on /home. Either: # xfs_quota -x -c "quota -N -u brian" or # xfs_quota -x -c "quota -N -u brian" /home /share will not output the error message because xfs_quota knows about the locations of the project quotas. Yes, it's not obvious what is happening here but technically it isn't a bug, either, because you told xfs_quota not to load information about any other mountpoint. I'll have a think about how to make this output less .... obtuse. Cheers, Dave.
Hello, Thanks for your response. I am kind of confused still. I asked for user quotas, with the -u flag. Why should it be trying to lookup project quotas? I only want to get the report of user quotas. I only want to get the report for one filesystem. A filesystem that doesn't support project quotas, which should be fine because I am not asking for project quotas. This was fine under lenny, but broke under squeeze. This prints the quota information 20 times. Huh? This prints the quota information 2 times. Huh? hq ~ # xfs_quota -x -c "quota -u brian" /home /share Disk quotas for User brian (10000) Filesystem Blocks Quota Limit Warn/Time Mounted on /dev/mapper/hq-home 3799724 0 0 00 [--------] /home /dev/mapper/hq-share 282856 0 0 00 [--------] /share Disk quotas for User brian (10000) Filesystem Blocks Quota Limit Warn/Time Mounted on /dev/mapper/hq-home 3799724 0 0 00 [--------] /home /dev/mapper/hq-share 282856 0 0 00 [--------] /share Thanks
Because the quota command does mount point and project quota initialisation (i.e. global state) before it parses any specific command. The issues project quota configuration is global information, and the initialisation code is not aware of the fact that: a) you are not asking for project quota information; and b) you are not asking for information about a mount point that doesn't have any project quotas on it. How many mount points do you have? 20? The command has once for each of the mount points, and the command itself iterates mount points because you haven't given it a mount point to look at. So, double iteration. This same problem was fixed for the report command by setting it to be a global command i.e. the fix I mentioned previously that you tested should prevent this second case, and maybe even the first. There are several layers of interactions here, and that's why I need to have a think about it to understand it fully and fix it.... Cheers, Dave.
Oops. Just realized I still hadn't responded. Sorry.
No. More actually. Today I get
hq ~ # cat /proc/mounts | wc --lines
34
hq ~ # xfs_quota -x -c "quota -N -u brian" | wc --lines
44
hq ~ # xfs_quota -x -c "quota -N -u brian" /home /share | wc --lines
4
As far as I can tell this happens with the patched xfs_quota.
hq /home/brian/xfsprogs # git diff
diff --git a/quota/quot.c b/quota/quot.c
index a7782b4..6cb665d 100644
--- a/quota/quot.c
+++ b/quota/quot.c
@@ -418,6 +418,7 @@ quot_init(void)
quot_cmd.args = _("[-bir] [-gpu] [-acv] [-f file]");
quot_cmd.oneline = _("summarize filesystem ownership");
quot_cmd.help = quot_help;
+ quot_cmd.flags = CMD_FLAG_GLOBAL;
if (expert)
add_command("_cmd);
As this version is based on git, I just did a git pull:
hq /home/brian/xfsprogs # git pull
Updating b326e06..64ae7fc
Fast-forward
mkfs/xfs_mkfs.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
Doesn't look related to this, don't think I need to retest.