Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Sep 2008 08:07:49 -0500
From:      "Diego F. Arias R." <dak.col@gmail.com>
To:        "Josh Paetzel" <jpaetzel@freebsd.org>
Cc:        Danny Do <ai_quoc@hotmail.com>, freebsd-questions@freebsd.org
Subject:   Re: Optimal File System config for 2.5TB RAID5
Message-ID:  <3b93bd110809300607i34b26e2cy4648ab1c21bc6ec8@mail.gmail.com>
In-Reply-To: <48E21C66.8080407@FreeBSD.org>
References:  <1222681181.48e0a25d094c3@www.inbox.lv> <BAY139-DAV13C8982A51CD9B05C74D5090430@phx.gbl> <48E21C66.8080407@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 30, 2008 at 7:32 AM, Josh Paetzel <jpaetzel@freebsd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Danny Do wrote:
>> Hello,
>>
>> I am building a 6x500GB SATA HARDWARE RAID5 storage server to
>> - Store large files, 10BM~1GB/file
>> - Handling 500+ concurrent connections
>> - Transfer rate around 100~200Mbit/s
>>
>> I am thinking of using the patch from Wojciech Puchar to reduce hard drive
>> data seek in order to handle large number of concurrent connections whilst
>> outputting 100~200Mbit/s.
>>
>> patch /usr/src/sys/sys/param.h
>> #ifndef DFLTPHYS
>> #define DFLTPHYS        (1024 * 1024)   /* default max raw I/O transfer size
>> */
>> #endif
>> #ifndef MAXPHYS
>> #define MAXPHYS         (1024 * 1024)   /* max raw I/O transfer size */
>> #endif
>> #ifndef MAXDUMPPGS
>>
>>
>> To store files greater than 10MB, I come up with the following proposal for
>> my File System:
>> - UFS2
>> - Soft Update  Enable
>> - block-size   1,048,576
>>
>> I am not completely sure what advantage I got from this configuration but I
>> am pretty sure that FSCK is much quicker with 1M file system block-size.
>>
>> Is there any other thing I need to consider in term of performance and
>> reliability?
>>
>> I hope that this system will perform much better than my current 6x300GB
>> SCSI 10K RPM system.
>>
>> Appreciate any advice,
>>
>> Danny
>
> Why do you think slower drives using an interface that has known
> problems handling concurrent connections will be faster than faster
> drives using an interface designed for concurrency?
>
> Based on my experiences with SATA vs. U160/U320 SCSI or SAS your likely
> outcome is to see a marked decrease in performance.  I'd be interested
> to hear your results.
>
>
> - --
> Thanks,
>
> Josh Paetzel
>
> PGP: 8A48 EF36 5E9F 4EDA 5ABC 11B4 26F9 01F1 27AF AECB
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
>
> iD8DBQFI4hxmJvkB8SevrssRAqErAJ0Tt9WPT25RhkUfGVLxEzSykEMvtwCeKXRV
> jdgJ/whLeeAQ3E97i7FkB4w=
> =UyD6
> -----END PGP SIGNATURE-----
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
>
Interface concurrent connection problems?, do you have a link or something?

actually i recommend again the RAID 10, if you want performance for
heavy I/O (multiple reading,not only one file lineal reading)
for storage intensive apps its the way to go.


-- 
mmm, interesante.....



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3b93bd110809300607i34b26e2cy4648ab1c21bc6ec8>