> On 02/19/13 05:47, MJ wrote: >> Which app are you running that is generating millions of tiny files >> in a single directory? Regardless, in this case OpenBSD is not the >> right tool for the job. You need either FreeBSD or a Solaris variant >> to handle this problem because you need ZFS. >> >> >> What limits does ZFS have? --------------------------------------- >> The limitations of ZFS are designed to be so large that they will >> never be encountered in any practical operation. ZFS can store 16 >> Exabytes in each storage pool, file system, file, or file attribute. >> ZFS can store billions of names: files or directories in a directory, >> file systems in a file system, or snapshots of a file system. ZFS can >> store trillions of items: files in a file system, file systems, >> volumes, or snapshots in a pool. >> >> >> I'm not sure why ZFS hasn't yet been ported to OpenBSD, but if it >> were then that would pretty much eliminate the need for my one and >> only FreeBSD box ;-) > > The usual stated reason is "license", it is completely unacceptable to > OpenBSD. > > The other reason usually not given which I suspect would become obvious > were the license not an instant non-starter is the nature of ZFS. As it > is a major memory hog, it works well only on loaded 64 bit platforms. > Since most of our 64 bit platforms are older, and Alpha and SGI machines > with many gigabytes of memory are rare, you are probably talking an > amd64 and maybe some sparc64 systems. > > Also...see the number of "ZFS Tuning Guides" out there. How...1980s. > The OP here has a "special case" use, but virtually all ZFS uses involve > knob twisting and experimentation, which is about as anti-OpenBSD as you > can get. Granted, there are a lot of people who love knob-twisting, but > that's not what OpenBSD is about. > > I use ZFS, and have a few ZFS systems in production, and what it does is > pretty amazing, but mostly in the sense of the gigabytes of RAM it > consumes for basic operation (and unexplained file system wedging). > I've usually seen it used as a way to avoid good system design. Yes, > huge file systems can be useful, but usually in papering over basic > design flaws. > > Nick. > >
I feel anyone expecting to run any of the recently hatched filesystem on 10+ year old hardware falls into the design flaw category you mention. As for needing to turn nobs to get it to work properly this is not necessary if you use a modern 64bit box. Most of the tuning guides are written for the guys trying to use it on their old hardware. Or trying to reach "performance" numbers for whatever, usually misguided, reason. On a modern amd64 box it pretty much just works. As for a port to OpenBSD I'd love it, or port of LVM, but the biggest hurdle IMO is the same one that plagues so many other good potential OpenBSD ports. Getting someone competent and dedicated enough to do the work. I'm neither of those two things when it comes to porting, so I can only blame myself that I'm using FreeBSD on my file server and desktop instead of Open as I'd really like. However, I still have deep reservations about trusting ZFS long term since Oracle closed it off to the community again. I don't feel FreeBSD will be able to truly maintain the port over time. I hope I'm wrong but we will see. So it may be for the best that Open doesn't waste too much time on it. -- ESP
