Re: [Ext2-devel] Re: Latest ext3 patches (extents, mballoc, delayed allocation)
> Sonny Rao (SR) writes: SR> Alex, small buglet, If the FIBMAP-ioctl get's called on a file with SR> delayed allocation, you need to flush it (or at least allocate) before SR> returning the mappings. This doesn't seem to work properly at SR> present. good catch. thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: Latest ext3 patches (extents, mballoc, delayed allocation)
On Fri, Feb 11, 2005 at 11:40:21PM +0300, Alex Tomas wrote: > > Good day all, > > I've updated the patchset against 2.6.10. A bunch of bugs have been > fixed and mballoc now behaves smarter a bit. Extents and mballoc > patches collects some stats they print upon umount. NOTE: they must > not be used to store important data. A lot of things are to be done. > > Please review. Any comments and suggestions are very welcome. Alex, small buglet, If the FIBMAP-ioctl get's called on a file with delayed allocation, you need to flush it (or at least allocate) before returning the mappings. This doesn't seem to work properly at present. Sonny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: Latest ext3 patches (extents, mballoc, delayed allocation)
Alex Tomas wrote: Good day all, I've updated the patchset against 2.6.10. A bunch of bugs have been fixed and mballoc now behaves smarter a bit. Extents and mballoc patches collects some stats they print upon umount. NOTE: they must not be used to store important data. A lot of things are to be done. Thanks Alex, for the hard work. Please review. Any comments and suggestions are very welcome. Will do. The followins crazy listing shows tiobench's results for SMP box: Random Reads File Blk Num Avg CPU IdentifierSize Size Thr Rate (CPU%) Latency Eff -- - --- -- -- - - ext2 512 40961 119.05 40.37% 0.031 295 ext3 512 40961 134.78 37.08% 0.028 363 ext3rs512 40961 25.18 8.377% 0.154 301 The throughput here is really weird. Reservation code does not touch read code path. I could imagine that it maybe change the disk layout and make a difference on sequential reads, but I am not sure how it will affect the random read. And this is happening on 1 thread and 4 threads, but for 2 threads, reservation case is the best. I will see if I could repeat the same results here. Mingming - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
