Date: Fri, 21 Mar 2003 10:26:00 +1030 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Alexander Haderer <alexander.haderer@charite.de> Cc: Maarten de Vries <mdv@unsavoury.net>, Dirk-Willem van Gulik <dirkx@webweaving.org>, freebsd-questions@FreeBSD.ORG Subject: Re: Three Terabyte Message-ID: <20030320235600.GG60356@wantadilla.lemis.com> In-Reply-To: <5.2.0.9.1.20030320125711.019eb9c8@postamt1.charite.de> References: <20030320111436.N74106-100000@foem.leiden.webweaving.org> <20030320111436.N74106-100000@foem.leiden.webweaving.org> <5.2.0.9.1.20030320125711.019eb9c8@postamt1.charite.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--nhYGnrYv1PEJ5gA2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 20 March 2003 at 13:13:18 +0100, Alexander Haderer wrote: > At 12:53 20.03.2003 +0100, Maarten de Vries wrote: >> On Thu, 20 Mar 2003, Dirk-Willem van Gulik wrote: >> >>> Depends on what access patterns you have; is it mostly dormant >>> archiving; or lots of access, concurrent, sequential ? How safe does the >>> data need to be; and against what (hardware failure, accidental rm -rf). >> >> This would be for backup. Data on about 50 webservers would be backed up >> to it on a nightly basis. So performance wouldn't be important. > > Sure? Consider this: > > a. > Filling 3TB with 1 Mbyte/s lasts more than 800 hours or 33 days. I do a nightly backup to disk. It's compressed (gzip), which is the bottleneck. I get this sort of performance: dump -2uf - /home | gzip > /dump/wantadilla/2/home.gz ... DUMP: DUMP: 1254971 tape blocks DUMP: finished in 217 seconds, throughput 5783 KBytes/sec DUMP: level 2 dump on Thu Mar 20 21:01:31 2003 You don't normally fill up a backup disk at once, so this would be perfectly adequate. I'd expect a system of the kind that Maarten's talking about to be able to transfer at least 40 MB/s sequential at the disk. That would mean he could backup over 1 TB in an 8 hour period. > b. > Using ssh + dump/cpio/tar needs CPU power for encryption, especially when > multiple clients safe their data at the same time. You can share the compression across multiple machines. That's what was happening in the example above. > c. > When using FreeBSD 4.X a fsck after a hard reboot will block the server. > fsck'ing a full 3TB filesystem may need a long time. Its better to use > several smaller file systems. You don't have to fsck at boot time, not even in Release 4. > d. > Wrong parameters for newfs may slowdown large filesystems and waste lots of > space. Before using large filesystems read the manpage of newfs, especially > the topics about options -b -f -i Correct. Check the -m option (free space %) as well. There's no reason to waste 8% of the space. Greg -- See complete headers for address and phone numbers --nhYGnrYv1PEJ5gA2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE+elUQIubykFB6QiMRAlSdAJ9wog/xYhiKwgZDacrlAATv3jojmQCgo9al 6/uoxD3AjsoCyHGeOiY0SAc= =M7MP -----END PGP SIGNATURE----- --nhYGnrYv1PEJ5gA2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030320235600.GG60356>