Hey Florian & Bradley, On Sun, Jan 13, 2013 at 11:36:27AM -0500, Bradley C. Kuszmaul wrote: > Where can I read about extents and xfs? Look here: http://xfs.org/index.php/XFS_Papers_and_Documentation > On Sun, Jan 13, 2013 at 4:26 AM, Florian Weimer <fw@xxxxxxxxxxxxx> wrote: > > > * Bradley C. Kuszmaul: > > > > > The question I have: What will happen to the performance of other > > > threads doing read() and write() operations? Will hole-punching slow > > > down the other read() and write() operations running in other threads? > > > > Assuming that hole-punching creates extents (not sure if it does, you > > can check with filefrag or other tools), Yep, it can. For example, if you have one large extent and punch out the middle you end up with two in the block map. Use xfs_bmap to look at the extent list. > you might experience a > > slowdown during open(), when the entire list of extents is read from disk. The docs probably describe this better than I can, see the data extents section of the filesystem structure doc. Inline extent lists would already have been read in with the inode, so it's not more expensive than reading the inode itself because it's in the same block. If you have a large extent list in a btree you can expect it to be read in as you access the data. > > I once was a heavy Berkeley DB user and had files with dozens of gigabytes > > containing hundreds of thousands of extents, and open() times in the order > > of minutes were not unusual with a cold cache and other concurrent read > > activities from the same RAID device. Ouch. I would not have expected open times that bad. > > But these files grew over > > time—perhaps hole punching results in better locality of the extent data, > > so that reading it doesn't take so much time in your case. xfs_bmap could help answer that question... ;) Regards, Ben _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
