linux-kernel - Re: Ext3 vs NTFS performance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070503125741.GA1518@think.oraclecorp.com>
Date:	Thu, 3 May 2007 08:57:41 -0400
From:	Chris Mason <chris.mason@...cle.com>
To:	David Chinner <dgc@....com>
Cc:	"Cabot, Mason B" <mason.b.cabot@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Ext3 vs NTFS performance

On Thu, May 03, 2007 at 10:15:11AM +1000, David Chinner wrote:
[ bad fragmentation from a funky write one byte every 128k system ]
> 
> This only becomes a problem if the system has enough pages dirty to
> be triggering throttling so that the 1byte writes are converted before
> the data actually hits the server.
> 
> Even then, if you are on an XFS filesystem with a sunit/swidth set,
> the alocation alignments and speculative allocations will go a long
> way to preventing fragmentations.
> 
> If that doesn't work, then set the extent allocation size hint on the
> XFS inode to 128k or 256k to set the minimum all ocation size for the
> file to span the distance between the 1 byte writes. This attribute
> can be inherited from the parent directory on create, so it's a
> set and forget type of thing...
> 
> i.e. XFS has lots of ways to prevent perfromance from degrading
> on these sorts of issues.

I'm not surprised that XFS would fair the best in this workload,
but this sounds like a lot of magic that shouldn't be required.  The
fact that it is good to have the allocation knobs and delalloc in
general doesn't mean that samba shouldn't do the right thing and
preallocate the space in a sensible fashion.

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/