Lack of comments to what? I haven't seen whatever patches you've sent which means wither you didn't tag the email as "[PATCH N/M]..." or "[REVIEW]..." and I didn't notice the attachments (nope, I see
Lack of comments to what? I haven't seen whatever patches you've sent which means wither you didn't tag the email as "[PATCH N/M]..." or "[REVIEW]..." and I didn't notice the attachments (nope, I see
XFS's default mount options are in most cases sub-optimal, we should try to have more sensible defaults, so far I'm following some quick dave-powered recomendations: - version 2 logs - attr2 - lazy
Mkfs options ;) Given that 25% on a 4GB filesystem will allow about 5million inodes, I think it's probably reasonable to bring it down to 5% by the time we pass 1TB and 1% by 50TB..... Cheers, Dave.
FWIW any anaconda-installed xfs filesystems have been using attr2 since FC6, and after the initial pain, I haven't heard any reports of problems. larger logbuf count/size seems to be the other tuning
On 29.10.2007 15:03, Eric Sandeen wrote: Niv Sardi wrote: XFS's default mount options are in most cases sub-optimal, we should try to have more sensible defaults, so far I'm following some quick dave
Sorry for all the replies ;-) What would you think of a mkfs conf file like e2fsprogs has, which defines filesystem classes, and defaults for each? (small, news, largefile, etc...) -Eric
That makes more sense for ext2/3 where some meta-data isn't dynamically allocated as needed, for example, historically nntp servers used one file per article and would often run out of inodes.
well, anything that is fixed at mkfs time could use this... inode size, ag count, etc. If there are common use cases which would want different mkfs-fixed defaults, it might make sense. -Eric
Well, we already default to 8 logbufs, and 256k log buffers are not a win in a lot of situations. The log buffer size is a mount option, so it's much easier to tweak once we default to v2 logs... Che
It reserves allocation groups as "metadata only" for inode32 filesystems so data doesn't get placed in them untill all other space is full. So at 1TB, we don't use 25% of the filesystem until the oth
Another one for you - make the log larger. The kernel code supports a log of up to 2GB, so mkfs could making a larger log without requiring changes elsewhere. Cheers, Dave. -- Dave Chinner Principal
Eric Sandeen wrote: Niv Sardi wrote: Hello, XFS's default mount options are in most cases sub-optimal, we should try to have more sensible defaults, so far I'm following some quick dave-powered recom
Probably SELinux+Beagle attributes? Attribute "Beagle.Fingerprint" has a 25 byte value Attribute "Beagle.Uid" has a 22 byte value Attribute "Beagle.MTime" has a 14 byte value Attribute "Beagle.Filter