delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2006/11/25/22:12:34

X-Spam-Check-By: sourceware.org
Message-ID: <4569060F.3010507@tlinx.org>
Date: Sat, 25 Nov 2006 19:12:15 -0800
From: Linda Walsh <cygwin AT tlinx DOT org>
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>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019