Date: Tue, 15 Feb 2000 12:56:50 -0600 (CST) From: Joe Greco <jgreco@ns.sol.net> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: hackers@FreeBSD.ORG Subject: Re: Filesystem size limit? Message-ID: <200002151856.MAA66327@aurora.sol.net> In-Reply-To: <200002151817.KAA44544@apollo.backplane.com> from Matthew Dillon at "Feb 15, 2000 10:17:15 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> :S play.p0.s0 State: up PO: 0 B Size: 46 GB > :S play.p0.s1 State: up PO: 32 MB Size: 46 GB > :S play.p0.s2 State: up PO: 64 MB Size: 46 GB > :... > :S play.p0.s35 State: up PO: 1120 MB Size: 46 GB > :S play.p0.s36 State: up PO: 1152 MB Size: 46 GB > :S play.p0.s37 State: up PO: 1184 MB Size: 46 GB > :vinum -> > :Suspended > :# newfs -v /dev/vinum/rplay > :preposterous size -584318976 > : > :Bleah. :-( > : > :Just thought I'd mention it. I'm putting the machine into production, > :with the smaller filesystems that I originally intended, but it seemed > :noteworthy to pass this along. Dunno how many terabyte filesystem folks > :are out there. > > The scary thing about this posting is that Joe was able to construct his > 1TB+ filesystem with *ONLY* 37 hard drives. 37? 38. And you, a programmer! ;-) And that gets you 1.9TB (disk mfr counting-wise). I'd have loved to break 2TB but couldn't imagine how to handle the required number of scsi busses without botchery. I could get 1TB with only 20 drives. These _are_ 50GB drives. Imagine rebuilding the Tertiary Disk project at Berkeley with just two machines. :-) Worse, imagine doing the TD project as designed with 50GB drives. 370 50GB drives = 18.5TB. > The second scariest thing about this posting, which Joe didn't mention, > is that his sole reason for creating this filesystem is to store his collection > of Elvis movies! Huh? No. It's my pr0n server, dewd. Do you know how many nekkid pikturez you can stuff onto 1.8TB? Speaking of which, I'd like to compliment you on the overall design of the Diablo system. It has scaled very well to handle a hundred million articles on-spool. Dumping, hash table 67108864 entries, record size 28 <== :-) :-) :-) @268435472 diload: 104146775/104146944 entries loaded History file trim succeeded: -rw-r--r-- 1 news news 3184549904 Feb 15 05:53 /news/dhistory -rw-r--r-- 1 news news 3184549904 Feb 15 02:45 /news/dhistory.bak 3 hours to rebuild dhistory on a SMP machine. Sigh. /dev/vinum/news 14154136 8491456 5662680 60% /news /dev/vinum/n0 31805976 26465776 5340200 83% /news/spool/news/N.00 /dev/vinum/n1 31805976 26754544 5051432 84% /news/spool/news/N.01 /dev/vinum/n2 31805976 27787840 4018136 87% /news/spool/news/N.02 /dev/vinum/n3 31805976 26834120 4971856 84% /news/spool/news/N.03 /dev/vinum/n4 31805976 27609456 4196520 87% /news/spool/news/N.04 /dev/vinum/n5 31805976 26771072 5034904 84% /news/spool/news/N.05 /dev/vinum/n6 31805976 27396296 4409680 86% /news/spool/news/N.06 /dev/vinum/n7 31805976 26801120 5004856 84% /news/spool/news/N.07 /dev/vinum/n8 31805976 8 31805968 0% /news/spool/news/N.08 Yeah, I'm not using that last spool, so I could probably squeeze 120 million articles on here. No binaries obviously. I remember when local news admins were excited to be able to claim that they had a quarter of a million articles on spool. > p.s. I think large filesystems are another reason why NFS (and other remote > filesystems) is only going to become more important over time. I think "and other remote filesystems" is the concept. I'm using these spool servers instead of NFS. Many ISP's have done the NFS-mounted reader thing, and that works, if you've a NetApp or similar. However, NFS is so chatty, and NFS mounts tend to jam if the server dies. I think you'll continue to see a move towards some sort of "storage appliance" for various applications, just like the Diablo server is a storage appliance for Usenet articles. It's not exactly a filesystem, but it's similar in that it is a fit-for-purpose model to do the required task. Thanks for Diablo, Matt. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002151856.MAA66327>