On Fri, Aug 26, 2011 at 10:08:41AM +0200, Marc Lehmann wrote: > On Fri, Aug 12, 2011 at 02:05:30PM +1000, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > It only does that if the pattern of writes are such that keeping the > > preallocation around for longer periods of time will reduce > > potential fragmentation. > > That can only be false. Here is a an example that I saw *just now*: > > I have a process that takes a directory with jpg files (in this case, > all around 64kb in size) and loslessly recompresses them. This works > by reading a file, writing it under another name (single write() call) > and using rename to replace the original file *iff* it got smaller. The > typical reduction is 5%. no allocsize option is used. Kernel used was > 2.6.39. > > This workload would obviously benefit most by having no preallocaiton > anywhere, i.e. have all files tightly packed. > > Here is a "du" on a big directory where this process is running, every few > minutes: > > 6439892 . > 6439888 . > 6620168 . > 6633156 . > 6697588 . > 6729092 . > 6755808 . > 6852192 . > 6816632 . > 6250824 . > > Instead of decreasing, the size increased, until just before the last > du. Thats where I did echo 3 >drop_caches, which presumably cleared all > those inodes that have not been used for an hour and would never have been > used again for writing. That's the case of the unlinked inode being reused immediately and no having all it's state cleared correctly when recycled. That's the problem that was diagnosed and fixed when you reported the first problem. Can you tell me if your kernel has the bug fix or not, and if not, does applying the fix make the problem go away? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
