X-Spam-Check-By: sourceware.org Message-ID: <4569060F.3010507@tlinx.org> Date: Sat, 25 Nov 2006 19:12:15 -0800 From: Linda Walsh User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: cygwin AT cygwin DOT com CC: vdergachev AT rcgardis DOT com Subject: Re: NTFS fragmentation redux References: <456133E5 DOT 8000509 AT tlinx DOT org> <200611201252 DOT 31836 DOT vdergachev AT rcgardis DOT com> In-Reply-To: <200611201252.31836.vdergachev@rcgardis.com> Content-Type: multipart/mixed; boundary="------------060603050601080705000401" X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com --------------060603050601080705000401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Vladimir Dergachev wrote: > This is curious - how do you find out fragmentation of ext3 file ? I do not > know of a utility to tell me that. --- There's a debugfs for ext2/ext3 that allows you to dump all of the segments associated with an inode. "ls -i" dumps the inode number. A quick hack (attached) displays segments for either extX or (using xfs_bmap) xfs. I couldn't find a similar tool for jfs or reiser (at least not in my distro). > From indirect observation ext3 does not have fragmentation nearly that bad > until the filesystem is close to full or I would not be able to reach > sequential read speeds (the all-seeks speed is about 6 MB/sec for me, I was > getting 40-50 MB/sec). This was on much larger files though. --- On an empty partition, I created a deterministic pathological case. Lots little files all separated by holes. ext3 (default mount) just allocated 4k blocks in a first come-first serve manner. XFS apparently looked for larger allocation units as the file was larger than 4K. In that regard, it's similar to NT. I believe both use a form of B-Tree to manage free space. > Which journal option was the filesystem mounted with ? --- I can't see how that would matter, but default. For speed of test, I mounted both with noatime,async & xfs also got nodiratime and logbuffs=8 (or deletes take way long). > I actually implemented a workaround that calls "fsutil file createnew > FILESIZE" to preallocate space and then write data in append mode > (after doing seek 0). --- I wonder if it does the same thing as dd or if it uses the special call to tell the OS what to expect. FWIW, "cp" used some smallish number of blocks (4 or 8, I think), so it is almost guaranteed to give you about the worse possibly fragmented file! :-) Most likely the other file utils will give similar allocation performance (not so good). -linda --------------060603050601080705000401 Content-Type: text/plain; name="filefrags.ext" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="filefrags.ext" IyEvYmluL2Jhc2gKCmV4cG9ydCBkZWJ1Z2ZzPSQod2hpY2ggZGVidWdmcykK CmlmICgoJCM8MSkpOyB0aGVuIGVjaG8gIm5lZWQgZmlsZW5hbWUiID4mMiA7 IGV4aXQgMTsgZmkKCndoaWxlIFtbIC1uICIkMSIgXV07IGRvCglpZiBbICEg LWUgIiQxIiBdOyB0aGVuIGVjaG8gIk5hbWUgXCIkMVwiIGRvZXNuJ3QgZXhp c3QuIElnbm9yaW5nIiA+JjIKCWVsc2UKCQlpbm9kZT0kKGxzIC1pICIkMSJ8 Y3V0IC1kXCAgLWYxKQoJCWVjaG8gLW4gIiQxOiAiCgkJUEFHRVI9Y2F0ICRk ZWJ1Z2ZzIC9kZXYvaGRjMSAtUiAic3RhdCA8JGlub2RlPiIgMj4vZGV2L251 bGwgfCBmcmFnZmlsdC5leHQKCWZpCglzaGlmdApkb25lCgojIHZpbTp0cz00 OnN3PTQ6Cg== --------------060603050601080705000401 Content-Type: text/plain; name="fragfilt.ext" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="fragfilt.ext" IyEvdXNyL2Jpbi9wZXJsIC13CgpteSAkbGluZW5vPTA7Cm15ICRmcmFncz0w OwoKd2hpbGUgKDw+KSB7CgkrKyRsaW5lbm87CgljaG9tcDsKCS9eIFwoIFxk K1teXCldKiBcKSA6XGQrW14sXSosL3ggJiYgZG8gewoJCW15IEBibG9ja19y YW5nZXM7CgkJbXkgQGJsb2NrbnVtczsKCQlteSBAdGhpc19yYW5nZTsKCgkJ cy9cKFteXClcbl0rXCk6Ly9nOwoJCXMvLC8vZzsKCQlAYmxvY2tfcmFuZ2Vz ID0gc3BsaXQgLyAvOwoJCWZvcmVhY2ggKEBibG9ja19yYW5nZXMpIHsKCQkJ cy8tLy4uLzsKCQkJQHRoaXNfcmFuZ2U9ZXZhbDsKCQkJcHVzaCBAYmxvY2tu dW1zLCBAdGhpc19yYW5nZTsKCQl9CgkJbXkgJGJuPSRibG9ja251bXNbMF07 CgkJcHJpbnQgIiQjYmxvY2tudW1zIGJsb2NrcyI7CgkJbXkgJGZyYWdzPTE7 CgkJZm9yICgkaT0xOyAkaSA8ICQjYmxvY2tudW1zOyArKyRpKSB7CgkJCW15 ICRuYm49JGJsb2NrbnVtc1skaV07CiMJCQlwcmludCAiYm49JGJuLCBuYm49 JG5ibjsgIjsKCQkJaWYgKCRibisxICE9ICRuYm4gKSB7CiMJCQkJcHJpbnQg IkhpY2N1cCwgc2tpcCAoJGJuIC0+ICRuYm4pXG4iOwoJCQkJKyskZnJhZ3M7 CgkJCX0KCQkJJGJuPSRuYm47CgkJfQoJCWxhc3Q7CiMJCW5leHQ7Cgl9Owp9 CmlmICgkZnJhZ3M9PTApIHsKCXByaW50ICJObyBmcmFnbWVudHMgaW4gZmls ZSwgKGxlbmd0aCA9IDA/KVxuIjsKCWV4aXQgMTsKfQppZiAoJGZyYWdzPT0x KSB7CglwcmludCAiLCBmdWxseSBkZWZyYWdtZW50ZWRcbiI7Cn0gZWxzZSB7 CglwcmludCAiIGluICRmcmFncyBmcmFnbWVudHNcbiI7Cn0KCiMgdmltOnRz PTQ6c3c9NAo= --------------060603050601080705000401 Content-Type: text/plain; charset=us-ascii -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ --------------060603050601080705000401--