xfs logbufs default, (also noatime, lazy-count(of partition formatter)...32767b v. 32768b...
Is there a reason why logbufs=8 should't become the default? Isn't it the best choice for most users given today's memory constraints (or lack thereof?)
I saw a message about xfs parameter tuning and still see the mention to:
'logbufs=8,noatime' having to be specified on every mount.
If the desire is to provide default optimal tuning, maybe a default of logbufs to 8 would be a good idea, and maybe a mkfs flag to default to 'noatime' and a 64MB internal log
size would be good ideas for *most* users?
How much of problem is defaulting to a 64MB internal log size when file partitions are measured in the 100GB range?
I'm not sure how much use it is to even remember typing lazy-count=1 on the size partition each time.
One more 'nit', while I think of it...for a 64MB log buffer size, one should be able to specify 32768b, but last I tried, that gave a 'too large' error...isn't 32768*4=64MB, not 32767b?
What's really created when I use the 32767b max? 64MB or "64MB-4K"? (maybe it doesn't matter, but if a log process wrote exactly 16MB chunks, it would be a bit short on the 4th
write..)...
-l
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 3 lines · Linda A. Walsh
Is there a reason why logbufs=8 should't become the default? Isn't it the best choice for most users given today's memory constraints (or lack thereof?)
It is the default:
#define XLOG_MAX_ICLOGS 8
if (mp->m_logbufs <= 0)
log->l_iclog_bufs = XLOG_MAX_ICLOGS;Quoted 2 lines
I saw a message about xfs parameter tuning and still see the mention to:
'logbufs=8,noatime' having to be specified on every mount.
you can't believe everything you read on the internets ;)
Quoted 3 lines
If the desire is to provide default optimal tuning, maybe a default of logbufs to 8 would be a good idea, and maybe a mkfs flag to default to 'noatime' and a 64MB internal log
size would be good ideas for *most* users?
noatime is something a user should choose based on their needs, not a default. Some things depend on atime, and noatime isn't really posix-compliant...
Log size depends on the fs size...
Quoted 2 lines
How much of problem is defaulting to a 64MB internal log size when file partitions are measured in the 100GB range?
/*
* With a 2GB max log size, default to maximum size
* at 4TB. This keeps the same ratio from the older
* max log size of 128M at 256GB fs size. IOWs,
* the ratio of fs size to log size is 2048:1. */
100*1024/2048
50
so it currently scales to 50M for 100G.
Quoted 2 lines
I'm not sure how much use it is to even remember typing lazy-count=1 on the size partition each time.
lazy-count will/should be the default soon; someone (me) just needs to make xfstests cope with the change first.
Quoted 3 lines
One more 'nit', while I think of it...for a 64MB log buffer size, one should be able to specify 32768b, but last I tried, that gave a 'too large' error...isn't 32768*4=64MB, not 32767b?
seems fine?
$ /sbin/mkfs.xfs -dfile,name=fsfile,size=100g -lsize=32768b
meta-data=fsfile isize=256 agcount=4, agsize=6553600 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=26214400, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=32768, version=2
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0-Eric
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs