From: Eric Sandeen <sandeen@sandeen.net>
To: "Theodore Y. Ts'o" <tytso@mit.edu>, fstests@vger.kernel.org
Subject: Re: [PATCH] generic/386: check the correct field from df output
Date: Tue, 24 Dec 2019 10:02:16 -0800 [thread overview]
Message-ID: <3f863ffd-cbee-222c-a353-9108107daf9e@sandeen.net> (raw)
In-Reply-To: <20191222213032.GC108990@mit.edu>
On 12/22/19 3:30 PM, Theodore Y. Ts'o wrote:
> On Sun, Dec 22, 2019 at 04:27:30PM -0500, Theodore Ts'o wrote:
>> ... However, looking at xfsprogs's quota command, I
>> see no evidence that there is any line breaking logic.
>
> Eric, since you're the xfsprogs maintainer --- am I missing something?
> Was there a line breaking feature in the past?
>
> - Ted
>
The logic is in the free_space() function.
if (flags & HUMAN_FLAG) {
count = fprintf(fp, "%-12s", path->fs_name);
if (count > 13)
fprintf(fp, "\n%12s", " ");
} else {
count = fprintf(fp, "%-19s", path->fs_name);
if (count > 20)
fprintf(fp, "\n%19s", " ");
}
eguan made this change to xfstests to handle it:
commit 50f2346560487303b381d11bbe52b93cd0a887bd
Author: Eryu Guan <eguan@redhat.com>
Date: Tue Oct 14 22:59:38 2014 +1100
xfs/262: update filter to deal with long device name correctly
If the device name is too long, the output of xfs_quota -c "df" will be
broke into two lines as
Filesystem 1K-blocks Used Available Use% Pathname
/dev/mapper/rhel_hp--dl388eg8--01-testlv2
15718400 32932 15685468 0% /mnt/testarea/scratch
/dev/mapper/rhel_hp--dl388eg8--01-testlv2
512000 0 512000 0% /mnt/testarea/scratch/test
and _filter_quota_rpt() couldn't catch the correct available number and
test will fail as
[root@hp-dl388g8-01 xfstests]# diff -u tests/xfs/262.out /root/xfstests/results//xfs/262.out.bad
--- tests/xfs/262.out 2014-10-08 20:16:19.000000000 +0800
+++ /root/xfstests/results//xfs/262.out.bad 2014-10-09 14:29:38.795813323 +0800
@@ -1,2 +1,4 @@
QA output created by 262
Silence is golden.
+hard limit 0 bytes, expected 524288000
+hard limit 0 bytes, expected 524288000
Update the filter so it could catch the correct value.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Does:
- bsize = byte_size($(NF-2));
+ bsize = byte_size($(NF-4));
fix it properly on ext4?
next prev parent reply other threads:[~2019-12-24 18:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-22 21:27 [PATCH] generic/386: check the correct field from df output Theodore Ts'o
2019-12-22 21:30 ` Theodore Y. Ts'o
2019-12-24 18:02 ` Eric Sandeen [this message]
2019-12-23 1:24 ` Yang Xu
2019-12-29 16:05 ` Eryu Guan
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=3f863ffd-cbee-222c-a353-9108107daf9e@sandeen.net \
--to=sandeen@sandeen.net \
--cc=fstests@vger.kernel.org \
--cc=tytso@mit.edu \
/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