[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-hackers
Subject: Re: per-directory quotas possible on 5.x ?
From: Robert Watson <rwatson () freebsd ! org>
Date: 2003-06-30 21:07:41
[Download RAW message or body]
On Mon, 30 Jun 2003, Josh Brooks wrote:
> On Mon, 30 Jun 2003, Robert Watson wrote:
>
> > As you may have noticed in trying the vn-backed mechanism, there are some
> > inefficiencies that turn up in FreeBSD when have large numbers of
> > pseudo-devices, etc. The resizing problem is real, also, since we don't
> > have online file system resizing. FWIW, a file system like HFS+ (which
> > has a much more strict directory hierarchy) would lend itself to directory
> > quotas much more. A port of HFS+ to FreeBSD was recently posted to
> > freebsd-fs.
>
> Thank you for your very informative response. I am curious, what sort
> of inefficiencies do turn up when you have large numebers of pseudo
> devices ?
>
> Do you have any comments on a system running, say, 100 vn-backed mounted
> filesystems ? 200 ? (presume moderate to heavy activity in each ...)
I've observed two problems when using large numbers of pseudo-devices:
(1) Hard upper limits on the number of such devices that can exist (I
don't remember the current limits, but on -STABLE I seem to recall
it's around 512).
(2) Increased chances of a deadlock if you have lots of vn backing files
in the same directory and you perform directory operations on the
directory. This has been observed on -STABLE with a few hundred
active chroots on vn-backed devices in jails. There have been some
mitigating changes in -CURRENT recently that decrease the chances of
this happening. The -STABLE workaround was to put each backing file
in its own subdirectory if the problem occurs on your system with your
workload.
On -CURRENT, you can also use the GPT partition layout which makes it
possible to have a lot more partitions on a disk than the BSD label format
or MBR. Using disk partitions makes things a little more difficult to
resize, but not hugely more, and avoids going through a file system
loopback, improving performance (and eliminating the chances of (2)
above).
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic