On Mon, Apr 14, 2014 at 12:23:47PM +1000, Dave Chinner wrote: > On Sat, Apr 12, 2014 at 10:01:54AM +0200, Christoph Hellwig wrote: > > This series is a major overhaul of the filestream allocator. The main point > > is to use the dcache to get the parent and avoiding to maintain a fstrm_item > > for each inode that the filestream is applied to in favor of just tracking > > the parent, but there's various more or less related fallout from this as well. > > OVerall it looks good. I'll need to do some testing on it and > have a deeper look at the main use-the-dentry-cache patch, but it > removes a heap of complexity and code and gets rid of the use of > inode IO locks, so there's a loot to like here... So I've looked over this in more detail and done some testing on it, and apart from the comment I made about a function name, I can't spot any problems with the code. In terms of testing, this passes all of the filestreams group tests except of xfs/172, which still randomly fails. That makes it at least as reliable as the current code. However, the failure of xfs/172 is interesting. It is expecting buffered IO to *fail* due to a short filestreams timeout that is set. However, when it fails, it's actually separating the streams correctly: $ cat results//xfs/172.full stream 1 AGs: 0 0 0 0 0 4 4 4 stream 2 AGs: 1 1 1 1 1 5 5 5 stream 3 AGs: 2 2 2 2 2 6 6 6 stream 4 AGs: 3 3 3 3 3 7 7 7 - streams are in separate AGs, expected _matching_ $ And that's because it's able to create an association with it's parent at allocation time rather than create time. So, the test failure is actually a case of "this works better than the old code" and not a negative at all. And you can see where the AGs filled up in this test, and so new associations for the streams had to be made, and that worked just fine, too. I've done some other, higher bandwidth testing similar to realtime file-per-frame video ingest for 2k resolution video (12.8MB files, writing as fast as possible using direct IO with a directory per "video") and that works just fine at the limits of my local hardware (about 850MB/s to disk). So I'm going to modify the function name I disliked, and commit this to a topic branch and push it into the for-next branch for wider testing. If we need further modifications, we can fix them up later.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
