Date: Sun, 16 Jan 2000 11:54:42 +0530 From: Greg Lehey <grog@lemis.com> To: Joseph Scott <joseph.scott@owp.csus.edu> Cc: Sean Heber <sean@bebits.com>, freebsd-questions@FreeBSD.ORG Subject: Re: Are huge file systems bad? Message-ID: <20000116115442.D3413@mojave.worldwide.lemis.com> In-Reply-To: <387CFB4E.827314D9@owp.csus.edu>; from joseph.scott@owp.csus.edu on Wed, Jan 12, 2000 at 02:08:14PM -0800 References: <002d01bf5d43$845331e0$0a04cfd1@mwci.net> <387CFB4E.827314D9@owp.csus.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 12 January 2000 at 14:08:14 -0800, Joseph Scott wrote:
>
> Sean Heber wrote:
>>
>> I'm setting up a server that needs a lot of storage area online via web and
>> ftp. Basically, what we're doing is giving our >650 registered developers
>> ftp access so they do not have to find alternative hosting providers.
>>
>> Basically, my question is 2-fold..
>>
>> 1) Are huge file systems bad? I have concatenated two large drives
>> together using vinum. The resulting file system is 50Gig.
>>
>> 2) Is there another way to structure this that would keep file systems
>> small but be easy to manage if number 1 is bad?
>>
>> Our structure for the ftp site has the ftp dir for each user under
>> /sites/ftp/usr. So like this:
>>
>> usr/bdev1
>> usr/bdev2
>> usr/bdev3
>> usr/bdev4
>> usr/bdev5
>> ...
>>
>> As far as I can tell, that makes it very hard to break up all the space into
>> smaller partitions. So that's why I went the vinum route. However, I've
>> had conflicting reports that large file systems can be really dangerous. So
>> I'd like to know for sure.
>>
>> Yes, this 50GB will be backed up. But I want to avoid any unnecessary
>> problems ahead of time.
>
> From my reading of the different lists I believe the following is the
> situation as it stands now :
>
> 1. Large file systems themselves are not a problem in BSD. Several
> people have reported having very large file systems on FreeBSD. ( IE
> : 100G or so ).
I've always been an advocate of large file systems, but there are some
drawbacks:
1. If you have a crash, the fsck time can be considerable. I don't
know if it's any worse than fsck'ing several smaller file systems
with the same total size, however.
2. Backing up and restoring can be a challenge. I've tended to say
"don't make your file systems larger than your tapes", but there
are exceptions, especially if you can back up at the subdirectory
level. For the same reason, multi-reel backups can be
counterproductive. If for some reason you accidentally delete a
file and need to restore it from tape, you may find it takes 8
hours or longer, reading through tapes you don't need to look at.
> 2. File systems are large IDE drives seem to be a problem, several
> people have reported having problems making these large ( ~30G ) disks
> one file system. The solution thus far has been to break it up into
> multiple filesystem. I'm not sure exactly where this limit is,
> possible around ~25G, maybe less. I'm expecting a ~30G IDE disk with
> in the next few weeks and will see how big I can make it. The IDE
> drivers in FreeBSD are being replaced so I don't think there will be
> much work done towards solving this problem until the new drivers are
> in -STABLE and can be tested with these large IDE drives.
We're pretty sure we have fenced this bug in now. It only applies to
IDE drives using the wd driver in CHS mode. If you use the at driver
(due for release in 4.0-RELEASE), or use the wd driver in LBA mode,
you won't have this problem. Nobody has reported problems running IDE
drives under vinum, though I suspect the problem would occur there as
well.
> Depending on what kind of peak load you are looking at then splitting
> things up ( via vinum or separate disks ) may buy you some performance
> also. I'm sure there are someways to make splitting up the dir's on
> to separate file systems managable. Symlinks? Maybe a different
> naming scheme, like :
>
> usr/a/adev1
> usr/a/adev2
> usr/b/bdev1
> usr/b/bdev2
This is a different issue. If you have a large number of files in a
directory, the search time can become considerable. This method can
improve matters.
Greg
--
When replying to this message, please copy the original recipients.
For more information, see http://www.lemis.com/questions.html
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers
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?20000116115442.D3413>