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)
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)
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)
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/
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/
Re: Latest ext3 patches (extents, mballoc, delayed allocation)
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. The patches are too big to send in a message (previous time they got rejected). I put them in ftp://ftp.clusterfs.com/pub/people/alex/2.6.10 The following names are used: ext3rs - ext3 mounted with data=writeback,reservation options ext3i - ext3 mounted with extents,mballoc,delalloc options reiser - reiserfs v3 I did some benchmarking. Two systems were used: SMP - dual PIII-1GHz, 1GB, FC-connected to 2 disks raid0 UP - PIII-933MHz, 256MB, FC-connected to 2 disks raid0 The tests dd500 and dd1000 generate 500M and 1000M using dd on fresh fs. Real time varies run from run because of disks, but sys.time is stable. SMPUP TEST / FS real sys real sys dd500/ext2 - 9.14 2.3319.03 2.50 dd500/ext3 - 12.23 4.0618.99 4.19 dd500/ext3rs- 13.39 4.0115.08 4.16 dd500/ext3i - 9.19 2.3119.07 2.52 dd500/reiser- 7.95 2.8721.23 3.09 dd500/xfs - 17.88 2.4219.25 2.67 dd1000/ext2 - 37.47 4.6944.59 5.02 dd1000/ext3 - 38.03 7.9040.77 8.31 dd1000/ext3rs - 34.62 7.9540.51 8.30 dd1000/ext3i- 33.73 4.6538.74 4.93 dd1000/reiser - 29.29 5.7944.88 6.08 dd1000/xfs - 37.11 5.0339.98 5.27 The test untar unpacks linux-2.6.0.tar: SMP UP TEST / FS real sys real sys untar/ext2 - 9.21 2.4727.31 2.57 untar/ext3 - 15.63 3.3834.54 3.61 untar/ext3rs- 15.91 3.2735.98 3.65 untar/ext3i - 8.33 2.7016.75 2.84 untar/reiser- 13.38 5.4725.88 5.96 untar/xfs - 44.62 5.6451.92 4.88 The next test is dbench: SMP UP TEST / FS real sys MB/s real sys MB/s dbench1/ext2- 5.87 1.4363.72565.93 1.5463.79 dbench1/ext3- 2.46 1.75139.7943.60 1.85131.372 dbench1/ext3rs - 2.46 1.73140.3783.55 1.85133.071 dbench1/ext3i - 2.19 1.48156.9762.28 1.53150.403 dbench1/reiser - 2.80 2.05122.7612.88 2.11119.815 dbench1/xfs - 2.83 1.81122.1592.87 1.91119.564 dbench4/ext2- 4.99 7.13274.2169.96 6.22137.316 dbench4/ext3- 5.79 8.64236.85811.49 7.40130.146 dbench4/ext3rs - 5.80 8.57236.35611.45 7.38130.467 dbench4/ext3i - 5.16 7.16265.6219.25 6.31147.872 dbench4/reiser - 7.11 10.85 192.49111.85 8.59115.392 dbench4/xfs - 6.60 8.88207.59911.98 7.69114.177 dbench8/ext2- 16.04 14.27 181.93 18.32 12.14 149.228 dbench8/ext3- 18.87 17.04 165.21423.77 14.88 119.995 dbench8/ext3rs - 11.52 17.21 237.64723.35 15.04 123.088 dbench8/ext3i - 11.20 14.66 268.05221.00 12.49 130.223 dbench8/reiser - 13.92 21.65 196.30624.98 17.67 114.083 dbench8/xfs - 14.84 18.23 184.26325.84 15.53 105.743 dbench16/ext2 - 20.39 28.79 267.97947.37 25.13 115.582 dbench16/ext3 - 25.69 34.54 212.74553.43 30.78 102.266 dbench16/ext3rs - 24.47 34.36 223.37 54.68 30.44 100.082 dbench16/ext3i - 22.94 29.40 238.21544.89 25.73 121.962 dbench16/reiser - 28.56 43.86 191.40756.48 36.41 96.9686 dbench16/xfs- 33.49 36.94 163.15978.68 32.56 69.4764 dbench32/ext2 - 43.54 58.87 250.947108.1 51.24 101.354 dbench32/ext3 - 61.83 70.66 176.707139.84 63.77 78.8818 dbench32/ext3rs - 67.24 71.69 162.651145.03 63.38 75.5155 dbench32/ext3i - 55.29 59.41 197.757100.24 52.50 109.26 dbench32/reiser - 76.32 93.45 143.127128.77 77.94 85.7179 dbench32/xfs- 119.4 88.09 91.4746670.45 76.19 16.298 The followins crazy listing shows tiobench's results for SMP box: Sequential Reads File Blk Num Avg CPU IdentifierSize Size Thr Rate (CPU%) Latency Eff -- - --- -- -- - - ext2 512 40961 40.95 12.80% 0.095 320 ext3 512 40961 45.03 13.99% 0.086 322 ext3rs512 40961 50.53
Re: Latest ext3 patches (extents, mballoc, delayed allocation)
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. The patches are too big to send in a message (previous time they got rejected). I put them in ftp://ftp.clusterfs.com/pub/people/alex/2.6.10 The following names are used: ext3rs - ext3 mounted with data=writeback,reservation options ext3i - ext3 mounted with extents,mballoc,delalloc options reiser - reiserfs v3 I did some benchmarking. Two systems were used: SMP - dual PIII-1GHz, 1GB, FC-connected to 2 disks raid0 UP - PIII-933MHz, 256MB, FC-connected to 2 disks raid0 The tests dd500 and dd1000 generate 500M and 1000M using dd on fresh fs. Real time varies run from run because of disks, but sys.time is stable. SMPUP TEST / FS real sys real sys dd500/ext2 - 9.14 2.3319.03 2.50 dd500/ext3 - 12.23 4.0618.99 4.19 dd500/ext3rs- 13.39 4.0115.08 4.16 dd500/ext3i - 9.19 2.3119.07 2.52 dd500/reiser- 7.95 2.8721.23 3.09 dd500/xfs - 17.88 2.4219.25 2.67 dd1000/ext2 - 37.47 4.6944.59 5.02 dd1000/ext3 - 38.03 7.9040.77 8.31 dd1000/ext3rs - 34.62 7.9540.51 8.30 dd1000/ext3i- 33.73 4.6538.74 4.93 dd1000/reiser - 29.29 5.7944.88 6.08 dd1000/xfs - 37.11 5.0339.98 5.27 The test untar unpacks linux-2.6.0.tar: SMP UP TEST / FS real sys real sys untar/ext2 - 9.21 2.4727.31 2.57 untar/ext3 - 15.63 3.3834.54 3.61 untar/ext3rs- 15.91 3.2735.98 3.65 untar/ext3i - 8.33 2.7016.75 2.84 untar/reiser- 13.38 5.4725.88 5.96 untar/xfs - 44.62 5.6451.92 4.88 The next test is dbench: SMP UP TEST / FS real sys MB/s real sys MB/s dbench1/ext2- 5.87 1.4363.72565.93 1.5463.79 dbench1/ext3- 2.46 1.75139.7943.60 1.85131.372 dbench1/ext3rs - 2.46 1.73140.3783.55 1.85133.071 dbench1/ext3i - 2.19 1.48156.9762.28 1.53150.403 dbench1/reiser - 2.80 2.05122.7612.88 2.11119.815 dbench1/xfs - 2.83 1.81122.1592.87 1.91119.564 dbench4/ext2- 4.99 7.13274.2169.96 6.22137.316 dbench4/ext3- 5.79 8.64236.85811.49 7.40130.146 dbench4/ext3rs - 5.80 8.57236.35611.45 7.38130.467 dbench4/ext3i - 5.16 7.16265.6219.25 6.31147.872 dbench4/reiser - 7.11 10.85 192.49111.85 8.59115.392 dbench4/xfs - 6.60 8.88207.59911.98 7.69114.177 dbench8/ext2- 16.04 14.27 181.93 18.32 12.14 149.228 dbench8/ext3- 18.87 17.04 165.21423.77 14.88 119.995 dbench8/ext3rs - 11.52 17.21 237.64723.35 15.04 123.088 dbench8/ext3i - 11.20 14.66 268.05221.00 12.49 130.223 dbench8/reiser - 13.92 21.65 196.30624.98 17.67 114.083 dbench8/xfs - 14.84 18.23 184.26325.84 15.53 105.743 dbench16/ext2 - 20.39 28.79 267.97947.37 25.13 115.582 dbench16/ext3 - 25.69 34.54 212.74553.43 30.78 102.266 dbench16/ext3rs - 24.47 34.36 223.37 54.68 30.44 100.082 dbench16/ext3i - 22.94 29.40 238.21544.89 25.73 121.962 dbench16/reiser - 28.56 43.86 191.40756.48 36.41 96.9686 dbench16/xfs- 33.49 36.94 163.15978.68 32.56 69.4764 dbench32/ext2 - 43.54 58.87 250.947108.1 51.24 101.354 dbench32/ext3 - 61.83 70.66 176.707139.84 63.77 78.8818 dbench32/ext3rs - 67.24 71.69 162.651145.03 63.38 75.5155 dbench32/ext3i - 55.29 59.41 197.757100.24 52.50 109.26 dbench32/reiser - 76.32 93.45 143.127128.77 77.94 85.7179 dbench32/xfs- 119.4 88.09 91.4746670.45 76.19 16.298 The followins crazy listing shows tiobench's results for SMP box: Sequential Reads File Blk Num Avg CPU IdentifierSize Size Thr Rate (CPU%) Latency Eff -- - --- -- -- - - ext2 512 40961 40.95 12.80% 0.095 320 ext3 512 40961 45.03 13.99% 0.086 322 ext3rs512 40961 50.53
