Is it possible to change sunit of log section post-mkfs
Hi!
I have a XFS file system which lies on a 10-disk RAID-6 device that was created with Chunk Size = 1MiB.
On mkfs.xfs time this was - as far as i know - specified with "-d su=1m,sw=8".
xfs_info shows the following:
meta-data=/dev/sdb1 isize=256 agcount=15,
agsize=268435200 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=3905945088, imaxpct=5
= sunit=256 swidth=2048 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=512 sunit=8 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0Interestingly, the sunit value of the log seems to be incorrect - as it should be 256 too, like the sunit value of the data. I am pretty sure the reason is that the log sunit cannot be 256 blks (=1024KiB) and because of this mkfs.xfs did fall back to the default of 8 blks (=32KiB). I found evidence of this in the following thread:
http://oss.sgi.com/archives/xfs/2012-06/msg00431.html
What i want to achieve is to set the log sunit to the maximum possible of 64 blks (=256KiB).
- Is that even possible without doing mkfs.xfs (and losing all data)?
- Would it be an improvement performance-wise?
- Would changing to an external log help?
tia,
Michael
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 24 lines · Michael Weissenbacher
Hi!
I have a XFS file system which lies on a 10-disk RAID-6 device that was created with Chunk Size = 1MiB.
On mkfs.xfs time this was - as far as i know - specified with "-d su=1m,sw=8".
xfs_infoshows the following:
meta-data=/dev/sdb1 isize=256 agcount=15,
agsize=268435200 blks= sectsz=512 attr=2 data = bsize=4096 blocks=3905945088, imaxpct=5 = sunit=256 swidth=2048 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=521728, version=2 = sectsz=512 sunit=8 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0Interestingly, the sunit value of the log seems to be incorrect - as it should be 256 too, like the sunit value of the data. I am pretty sure the reason is that the log sunit cannot be 256 blks (=1024KiB) and because of this mkfs.xfs did fall back to the default of 8 blks (=32KiB). I found evidence of this in the following thread:
http://oss.sgi.com/archives/xfs/2012-06/msg00431.html
Quoted 7 lines
What i want to achieve is to set the log sunit to the maximum possible of 64 blks (=256KiB).
- Is that even possible without doing mkfs.xfs (and losing all data)?
- Would it be an improvement performance-wise?
- Would changing to an external log help?
I don't believe there's any supported way to do this. Out of curiosity, I just tried an experiment to modify the superblock logsunit via xfs_db and run repair to zero the log. That seemed to work in terms of taking effect on the subsequent mount, but that's certainly not something I would suggest to do in production. Note that mkfs aligns the physical log based on the stripe unit as well, so it wouldn't really have the same effect anyways.
Brian
Quoted 7 lines
tia,
Michael_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Hi Brian!
Quoted 1 line · Brian Foster
I don't believe there's any supported way to do this.
Well, at least i didn't miss anything in the documentation :-)
Quoted 5 lines · Brian Foster
Out of curiosity,
I just tried an experiment to modify the superblock logsunit viaxfs_dband run repair to zero the log. That seemed to work in terms of taking effect on the subsequent mount, but that's certainly not something I would suggest to do in production.
Ok, so it would definitely be too risky for a production system.
Quoted 3 lines · Brian Foster
Note that mkfs aligns the physical
log based on the stripe unit as well, so it wouldn't really have the same effect anyways.
TBH, i didn't quite understand that part :-)
Are you saying, even if i would modify the log's sunit size using xfs_db, it would still not be aligned correctly?
thanks,
Michael
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 14 lines · Michael Weissenbacher
Hi Brian!
Quoted 1 line · Brian Foster
I don't believe there's any supported way to do this.
Well, at least i didn't miss anything in the documentation :-)
Quoted 5 lines · Brian Foster
Out of curiosity,
I just tried an experiment to modify the superblock logsunit viaxfs_dband run repair to zero the log. That seemed to work in terms of taking effect on the subsequent mount, but that's certainly not something I would suggest to do in production.Ok, so it would definitely be too risky for a production system.
Quoted 8 lines
Quoted 3 lines · Brian Foster
Note that mkfs aligns the physical
log based on the stripe unit as well, so it wouldn't really have the same effect anyways.TBH, i didn't quite understand that part :-)
Are you saying, even if i would modify the log's sunit size usingxfs_db, it would still not be aligned correctly?
Yes, exactly. mkfs uses the log stripe unit to decide where to put the log on disk. If the log itself is not aligned, then there's little use in aligning the writes to the log.
Brian
Quoted 7 lines
thanks,
Michael_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 24 lines · Michael Weissenbacher
Hi!
I have a XFS file system which lies on a 10-disk RAID-6 device that was created with Chunk Size = 1MiB.
On mkfs.xfs time this was - as far as i know - specified with "-d su=1m,sw=8".
xfs_infoshows the following:
meta-data=/dev/sdb1 isize=256 agcount=15,
agsize=268435200 blks= sectsz=512 attr=2 data = bsize=4096 blocks=3905945088, imaxpct=5 = sunit=256 swidth=2048 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=521728, version=2 = sectsz=512 sunit=8 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0Interestingly, the sunit value of the log seems to be incorrect - as it should be 256 too, like the sunit value of the data. I am pretty sure the reason is that the log sunit cannot be 256 blks (=1024KiB) and because of this mkfs.xfs did fall back to the default of 8 blks (=32KiB). I found evidence of this in the following thread:
http://oss.sgi.com/archives/xfs/2012-06/msg00431.html
Quoted 2 lines
What i want to achieve is to set the log sunit to the maximum possible of 64 blks (=256KiB).
Why? Is there a performance problem with the default setting?
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Hi Dave!
Quoted 3 lines
Quoted 3 lines
What i want to achieve is to set the log sunit to the maximum possible of 64 blks (=256KiB).
Quoted 3 lines · Dave Chinner
Why? Is there a performance problem with the default setting?
I am seeing very bad performance of "rm" on this file system. Of course I know that RAID-6 is kind of a worst case setup for that workload. But I was hoping that aligning the log correctly plus increasing the stripe size would help. Wouldn't the file system write more of the log at once with a bigger sunit size; resulting in fewer RMW cycles?
I am already using delaylog, inode64, nobarrier to mount the fs; lazy-count=1.
Maybe moving to an external log would be the best option?
tia,
Michael
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 7 lines · Michael Weissenbacher
Hi Dave!
Quoted 3 lines
Quoted 3 lines
What i want to achieve is to set the log sunit to the maximum possible of 64 blks (=256KiB).
Quoted 1 line · Dave Chinner
Quoted 7 lines
Quoted 2 lines
Why? Is there a performance problem with the default setting?
I am seeing very bad performance of "rm" on this file system. Of course I know that RAID-6 is kind of a worst case setup for that workload. But I was hoping that aligning the log correctly plus increasing the stripe size would help. Wouldn't the file system write more of the log at once with a bigger sunit size; resulting in fewer RMW cycles?
"rm is slow" could be many, many thingsr. Generally rm is limited by directory/inode read speed, not log IO. You need to find out exactly what is "slow" in rm before going knob twiddling. Is there iowait time? If so, what IO is generating the iowait? Is rm CPU bound? Is the log sleeping waiting for buffer space? is the log tail pushing? etc, etc.
Quoted 2 lines
I am already using delaylog, inode64, nobarrier to mount the fs; lazy-count=1.
IOWs, the defaults.
Quoted 1 line
Maybe moving to an external log would be the best option?
You haven't even determined that there's a problem with the log yet.
Twiddling knobs does not solve problems. Analyse the problem first, understand where the "slowness" is coming from, and that understanding will tell you is there's a knob that you can twiddle to alleviate the problem.
Keep in mind that if you have lots of inodes, small files and/or metadata intensive workloads, then it's very likely the RAID setup is the problem, not the filesystem.
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs