On Tue, Nov 03, 2015 at 08:32:14PM +0100, Michael Weissenbacher wrote: > Hi Dave! > > >> > >> What i want to achieve is to set the log sunit to the maximum possible > >> of 64 blks (=256KiB). > On 2015-11-03 20:11, Dave Chinner wrote: > > > > 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. > I am already using delaylog, inode64, nobarrier to mount the fs; > lazy-count=1. IOWs, the defaults. > 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. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
