Date: Thu, 12 Apr 2007 00:51:25 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: Dag-Erling =?us-ascii?Q?=3D=3Fus-ascii=3Aiso-8859-1=3FQ=3FSm=3DF8rgrav?= =?us-ascii?B?Pz0=?= <des@des.no>, ticso@cicely.de, freebsd-fs@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, Pawel Jakub Dawidek <pjd@FreeBSD.ORG> Subject: Re: ZFS committed to the FreeBSD base. Message-ID: <20070411225124.GM30772@cicely12.cicely.de> In-Reply-To: <20070411214911.GA38351@VARK.MIT.EDU> References: <20070406025700.GB98545@garage.freebsd.pl> <86k5wo55s0.fsf@dwp.des.no> <20070407203411.GJ8831@cicely12.cicely.de> <86wt0n3mxv.fsf@dwp.des.no> <20070411214911.GA38351@VARK.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 11, 2007 at 05:49:11PM -0400, David Schultz wrote: > On Sat, Apr 07, 2007, Dag-Erling Smrgrav wrote: > > Bernd Walter <ticso@cicely12.cicely.de> writes: > > > On Sat, Apr 07, 2007 at 09:43:59PM +0200, Dag-Erling Smørgrav wrote: > > > > ZFS is now also available on pc98 and amd64. > > > Great to read - is it just atomic.S missing for the remaining > > > architectures? > > > > Yes. Ideally, ZFS would use FreeBSD's atomic operations instead of > > its own. I believe that the reason it doesn't is (at least in part) > > that we don't have 64-bit atomic operations for i386. I have > > unfinished patches for cleaning up the atomic operations on all > > platforms; I'll dust them off and see what I can do. I already did a good cleanup of arm atomic functions based on your work a while ago. > As I recall, Solaris 10 targets PPro and later processors, whereas > FreeBSD supports everything back to a 486DX. Hence we can't > assume that cmpxchg8b is available. The last time I remember this > coming up, people argued that we had to do things slow way in the > default kernel for compatibility. 486 support is definitively needed, but it is very unlikely that many real existing 486 system has enough RAM for ZFS. AFAIK a ELAN520 can have up to 256MB, but I doubt that one would spend so much RAM for such a system without better use for it. Not shure about 586, this is more likely. But I'm not very familar with x86 assembly, so I don't even know which CPUs have cmpxchg8b. If ZFS wouldn't be so greedy I might have used it on flash media for x86 and ARM systems, but those boards usually don't have enough RAM. > Any ideas how ZFS and GEOM are going to work out, given that ZFS > is designed to be the filesystem + volume manager in one? Although you want to use ZFS RAID functionality GEOM has still many goodies avalable, such as md, ggate, partition-parsing, encyption, etc. There are other cool points, which I've found possible lately. E.g. replace all RAIDZ drives with bigger ones, export/import the pool and you have additional storage with the same number of drives. You just need a single additional drive at the same time, which is great in case you are short on drive bays. In case you accidently added a drive you didn't want to, you can't easily remove it, but you can workaround by replacing it with another one, which is equal or bigger in size. A short time workaround in such a case until you can backup/restore or replace the wrong drive with a long standing drive, you can use sparse md-vnode devices, ggate or gconcat ones. You just have to be carefull with sparse files, since ZFS don't care about it when filling with data, but you can at least detach your USB or firewire drive and hopefully live with the situation a few days. Today I tested a 6T Volume with sparse md files. This all worked really great. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070411225124.GM30772>