Please see my responses inline. I am seeing this behavior again.
On Tue, Aug 25, 2015 at 4:43 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> On Tue, Aug 25, 2015 at 04:09:33PM -0700, Shrinand Javadekar wrote:
>> I did this on 2 different setups.
>
> Details?
[Shri] On hardware box 1:
1. # of disks: 23
2. Type: Rotational disks
3. Ran mkfs.xfs and mounted disks
4. Installed Swift
5. Ran benchmark
6. Stopped Swift
7. unmounted disks
8. mkfs.xfs -f on all 23 disks
9. mounted disks
10. Installed Swift
11. Ran benchmark
Benchmark #s are as reported earlier.
The same steps mentioned above were performed on hardware box #2.
>
>> Formatted the new disks with mkfs.xfs. Ran the workload.
>> Reformatted the disks with mkfs.xfs -f. Ran the workload.
>>
>> >
>> >> Any ideas why this might be happening?
>> >
>> > With the paucity of information you've provided, nope!
>>
>> Apologies. What more information can I provide?
>
> http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
[Shri] I mentioned this in my first email. Here's the information:
http://oss.sgi.com/archives/xfs/2015-06/msg00108.html
>
>> > What version of xfsprogs are you using?
>>
>> # xfs_repair -V
>> xfs_repair version 3.1.9
>
> That's pretty old.
[Shri] We're using xfs progs version 3.1.9 whereas the kernel is newer
one: 3.16.0-38-generic. Does that matter?
For e.g. one of my colleagues found that the formatting with crc
enabled is only available in newer version of xfsprogs.
>
>> > What was the output of mkfs.xfs each time; did the geometry differ?
>>
>> I have the output of xfs_info /mount/point from the first experiment
>> and that of mkfs.xfs -f. One difference I see is that reformatting
>> adds projid32bit=0 for the inode section.
>
> xfs_info didn't get projid32bit status output until 3.2.0.
>
> Anyway, please post the output so we can see the differences for
> ourselves. What we need is mkfs output in both cases, and xfs_info
> output in both cases after mount.
Step 1: mkfs.xfs
Good formatting: http://pastie.org/private/new2zmwvdqvgm7h7coc4g
else:
meta-data=/dev/mapper/35000c50062e6a567-part2 isize=256 agcount=4,
agsize=183141504 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=732566016, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=357698, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Step 2: xfs_info
meta-data=/dev/mapper/35000c50062e6a567-part2 isize=256 agcount=4,
agsize=183141504 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=732566016, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=357698, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Step 3: Ran the benchmark (each run of 20GB)
Bandwidth (KB/s): 62294.9
Bandwidth (KB/s): 34407.7
Bandwidth (KB/s): 26949.8
Step 4: mkfs.xfs -f
Good formatting: http://pastie.org/private/bmzfateuuneddwg1zgymq
else:
meta-data=/dev/mapper/35000c50062e6a567-part2 isize=256 agcount=4,
agsize=183141504 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=732566016, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=357698, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Step 5: xfs_info
meta-data=/dev/mapper/35000c50062e6a567-part2 isize=256 agcount=4,
agsize=183141504 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=732566016, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=357698, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Step 6: Ran the same Benchmark (each run of 20GB):
Bandwidth (KB/s): 97061.6
Bandwidth (KB/s): 42811.7
Bandwidth (KB/s): 32111.7
-Shri
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
|