On Thu, Jan 27, 2011 at 04:56:20PM -0500, Mark Lord wrote: > On 11-01-27 02:40 PM, Stan Hoeppner wrote: > .. > > You need to use the mkfs.xfs defaults for any single drive filesystem, and trust > > the allocator to do the right thing. > > But it did not do the right thing when I used the defaults. > Big files ended up with tons of (exactly) 64MB extents, ISTR. Because your AG size is 64MB. An extent can't be larger than an AG. Hence you are fragmenting your large files unnecessarily, as extents can be up to 8GB in size on a 4k block size filesystem. > With the increased number of ags, I saw much less fragmentation, > and the drive was still very light on I/O despite multiple simultaneous > recordings, commflaggers, and playback at once. The allocsize mount option is the prefered method of keeping fragemntation down for dvr style workloads. > > Trust the defaults. > > I imagine the defaults are designed to handle a typical Linux install, > with 100,000 to 1,000,000 files varying from a few bytes to a few megabytes. Why would we optimise a filesystem designed for use on high end storage and large amounts of IO concurrency for what a typical Linux desktop needs? For such storage (i.e. single spindle) mkfs optimises the layout for minimal seeks and relatively low amounts of concurrency. This gives _adequate_ performance on desktop machines without compromising scalbility on high end storage. In my experience with XFS, most people who tweak mkfs parameters end up with some kind of problem they can't explain and don't know how to solve. And they are typically problems that would not have occurred had they simply used the defaults in the first place. What you've done is a perfect example of this. Yes, I know we are taking the fun out of tweaking knobs so you can say it's 1% faster than the default, but that's our job: to determine the right default settings so the filesystem works as well as possible out of the box with no tweaking for most workloads on a wide range of storage.... > That's not what this filesystem will have. It will have only a few thousand > (max) inodes at any given time, but each file will be HUGE. Which is exactly the use case XFS was designed for, and.... > XFS is fantastic at adapting to the workload, but I'd like to try and have > it tuned more closely for the known workload this system is throwing at it. .... as such the mkfs defaults are already tuned as well as they can be for such usage. > I'm now trying again, but with 8 ags instead of 8000+. Why 8 AGs and not the default? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
