Re: Looking for a Text on ZFS
Wojciech Puchar wrote: [snip] mirror. that's all. Which doesn't really address the issue of what happens if a drive that is part of a big ZFS is removed (because it's broken). it will say "read error" on all files and directories that happened to be placed on that disk! Just to be clear, ZFS pools contain one or more VDEVs (Virtual devices). Each VDEV consists of one or more physical partitions and can be configured as a mirror, stripe, stripe with one parity, or stripe with 2 parity. ZFS does striping with no parity across all VDEVs in the pool. Thus with ZFS, if you lose a VDEV, you lose the whole pool. Hopefully that clears things up a bit. Cheers, Drew [snip] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for a Text on ZFS
did you ever got your UFS filesystem broken not because your drive failed? That is not the point here. I have been using FreeBSD sind version 3.3, which was released in 1999. Before that I used Linux. So I can't even look while i was using linux - crashed filesystem was quite common without any disk failure. that's one of the reason i started using *BSD, another was performance. To answer the question: Yes, it did happen and not only once. This was in the time when I was setting up a new computer with 6.0-RELEASE and a new S-ATA controller. There was a bug in the driver which the developer managed to fix after we exhanged a few eMails. Before the error was fixed, my machine crashed several times with a kernel panic. There were something of course - with buggy driver it may be big problems. connected to the new controller and I was using this machine as a plattform to debug the driver, no real damage was caused. you of course will not use new/untested hardware/software combination for production machine? me too, so what a problem? That's ok to believe if you want to. UFS is designed to minimize errors. There is no guarantee that there will be none. there is never guarantee. if ZFS will calculate block checksum from memory and miscalculate it because of hardware/software problem, it will write it, and then write good data to say 2 disks. then it will take data from both disk and report uncorrectable error - without any error at all. just an example. there is no "ultimate" solution. systems still work. :-) my works too with one partition. so what a problem - except i had less work? still - making all in / is much easier and works fine. Maybe I'm just too conservative for that. in EVERY unix book it's repeated countless times that partitioning is good, and make it more secure, more prone to errors etc. it was - on original unix FS, but not on UFS, which automatically "partitions" your drive to cylinder groups. making all in / and /lessused, where / is at first part on disk, and /lessused on second - make big performance improvements (shorter seeks!). There are about 10 things I can think of that I'd do before I tried something like that. I'm a little surprised about a suggestion like this coming from you because you seem to be a great advocacy of dynamic what you mean "dynamic system"? systems. And here you have to decides what is used often and what not. This is an estimate that you could also mess up - I'm sure I probably would. :-) And chaninge a file from the seldom to the often area isn't that trivial either. i prefer / for everything. but sometimes i need this to speed things up, and definitely need it when using gmirror - to not waste lot of space by mirroring everything. i just mirror what's have to be mirrored. But ok, noone will judge either of us for working with our systems the way we please. :-) Anyone with Unix knowledge will find his way around my boxes and the same should be true for you. The rest are just details. :-) yes - but it's bad repeating "truth"s because it's said. ZFS advocacy first creates problems then solving it. i STRONGLY state most of these problems are artifical for most administrators and users. so ZFS may be useful for someone, but for most of as it's just waste of CPU and memory and... ours time (contrary to what ZFS stated - saving ours time). mirror. that's all. Which doesn't really address the issue of what happens if a drive that is part of a big ZFS is removed (because it's broken). it will say "read error" on all files and directories that happened to be placed on that disk! you understand quota as workaround of problems creating 1000 partitions. or simply - looks like you don't understand it at all, because it is not workaround. it's excellent tool. Maybe you just don't understand my English? :-) maybe..but you stated that quota is needed because partitions can't me easily created by mass. and that's exactly wrong. Quota does not address the different needs of certain applications. With quota you can limit the amount of inodes a user may grab but you cannot create areas with more inodes and others with less. Quota solves many in most cases average inode count is important with a bit excess. with rare cases really lots of files planned in some directory (like my squid spools) i make separate partitions. having this spools on separate partitions i can greatly reduce seeking as it's all in narrow part of disk plate. with ZFS it's no problem to have lots of small files, but they will be mixed up with other - without any control of placement. actually - i think it could be done automatically quite good, like few other things. maybe (i'm too lazy) i will write UFS3 ;) - but for sure it will be UFS-style filesystem, with some improvements. there is no need to revolution problems and is a great tool, no doubt in that, but it doesn't make your computer fast, you les
Re: Looking for a Text on ZFS
On Mon, 4 Feb 2008 13:39:52 +0100 (CET) Wojciech Puchar wrote: > did you ever got your UFS filesystem broken not because your drive failed? That is not the point here. I have been using FreeBSD sind version 3.3, which was released in 1999. Before that I used Linux. So I can't even look back on 10 years of FreeBSD yet and I don't have that many drives I have to worry about. So the fact if one of my files systems ever broke isn't really representative. To answer the question: Yes, it did happen and not only once. This was in the time when I was setting up a new computer with 6.0-RELEASE and a new S-ATA controller. There was a bug in the driver which the developer managed to fix after we exhanged a few eMails. Before the error was fixed, my machine crashed several times with a kernel panic. There were something like two dozen crashes in that time. Twice the filesystem could be salvaged by fsck, but the data on it was pretty messed up. I don't know how that happened and frankly, I don't care either. The rest of the times, fsck did get the fs into normal working order again whith just the file broken that was last being written. Since the boot drive wasn't connected to the new controller and I was using this machine as a plattform to debug the driver, no real damage was caused. > i don't. UFS it's not FAT, and doesn't break up. That's ok to believe if you want to. UFS is designed to minimize errors. There is no guarantee that there will be none. > you CAN't estimate well how much space you need in longer term. > in practice partitioning like yours means at least 100% more disk space > requirements. I wouldn't be that pessemistic. True, you can't be sure you allocated enough space to X, so you leave a safety margine. But the fact that the HDD doesn't grow limits your space anyway. I am not denying that you might waste space this way but it's still nothing I'd lose any sleep over. > of course - there are often cases today that whole system needs few gigs, > but smallest new drive is 80GB - it will work.. I work with lots of drives that are a lot smaller than that. And the systems still work. :-) > still - making all in / is much easier and works fine. Maybe I'm just too conservative for that. Mind you, I don't break up all drives by default. I have some 500GB drives that have only one large partition. This partition is for data (which means everything but system stuff). All I break up into pieces are the default system areas. > making all in / and /lessused, where / is at first part on disk, and > /lessused on second - make big performance improvements (shorter seeks!). There are about 10 things I can think of that I'd do before I tried something like that. I'm a little surprised about a suggestion like this coming from you because you seem to be a great advocacy of dynamic systems. And here you have to decides what is used often and what not. This is an estimate that you could also mess up - I'm sure I probably would. :-) And chaninge a file from the seldom to the often area isn't that trivial either. I increase performance by mounting /tmp and /usr/obj async and I mount systems I want to work fast with noatime. But ok, noone will judge either of us for working with our systems the way we please. :-) Anyone with Unix knowledge will find his way around my boxes and the same should be true for you. The rest are just details. :-) >> I read about this. However, I didn't find anything conclusive as to how >> well the drives can still live on their own if they are ever seperated. >> Now I don't think they will be addressed as a RAID0 with all the risks of >> that. But what happens if one of four drives breaks down? Does it make a >> difference, if the broken drive is the first one, the last one or a middle >> one? > > if it's just concat, you will loose lots of data, just like any other > filesystem. > with concat+mirror - you replace single drive that failed and rebuild > mirror. that's all. Which doesn't really address the issue of what happens if a drive that is part of a big ZFS is removed (because it's broken). > after reading your answer on 3-rd question i will end the topic, because > you understand quota as workaround of problems creating 1000 partitions. > or simply - looks like you don't understand it at all, because it is not > workaround. it's excellent tool. Maybe you just don't understand my English? :-) I understand quota very well and also what it can do. It is a very useful tool but it is not the holy grail. I actually use both block and file quote on some of the systems I have to watch. And I use both hard and soft at that. Quota does eliminate the need to create one partition for each home directory, even if you think it is not meant for that. And actually, it is used a lot for just that purpose. ISPs with shared hosting products usually don't allow direct write access outside the users ~ anyway. So the quota just stops him from uploading to much. But I know quota is also
Re: Looking for a Text on ZFS
/usr to spread the load while making worlds and I mount /usr/obj asynchronously to increase write speed. With several filesystems I can spread to load the way I want it and decide where the data goes. And one broken fs doesn't screw up the others in the process. did you ever got your UFS filesystem broken not because your drive failed? i don't. UFS it's not FAT, and doesn't break up. I do know the drawbacks of this: Storage is pretty static. Correcting wrong estimates about the needed fs-sizes is a big problem. That is why I you CAN't estimate well how much space you need in longer term. in practice partitioning like yours means at least 100% more disk space requirements. of course - there are often cases today that whole system needs few gigs, but smallest new drive is 80GB - it will work.. still - making all in / is much easier and works fine. making all in / and /lessused, where / is at first part on disk, and /lessused on second - make big performance improvements (shorter seeks!). 2) it takes many drives to the pool and you may add then new drives. same as gconcat+growfs. I read about this. However, I didn't find anything conclusive as to how well the drives can still live on their own if they are ever seperated. Now I don't think they will be addressed as a RAID0 with all the risks of that. But what happens if one of four drives breaks down? Does it make a difference, if the broken drive is the first one, the last one or a middle one? if it's just concat, you will loose lots of data, just like any other filesystem. with concat+mirror - you replace single drive that failed and rebuild mirror. that's all. after reading your answer on 3-rd question i will end the topic, because you understand quota as workaround of problems creating 1000 partitions. or simply - looks like you don't understand it at all, because it is not workaround. it's excellent tool. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for a Text on ZFS
On Sun, 3 Feb 2008 17:55:12 +0100 (CET) Wojciech Puchar wrote: > that's like 64-bit soundcards that have to be "better" than 32-bit, while > most of them was unable to actually get past 13-14 bit (most past 12) with > it's signal to noise ratio. Maybe that's not quite the same thing. :-) However. Even a 64bit filesystem still has gigantic reserves of space and although filling that may not cause the oceans to boil, any storage device that can actually sore all the date that a 64bit fs can allocate will be "pretty big" in terms of volume and mass and will also use a good deal of energy - even if this is calculated in the same minimalistic way as for ZFS: http://en.wikipedia.org/wiki/Zfs#Capacity Now I am not sure if the world actually needs a file system that can never be filled - with the limits not made by any feable estimates like we thought we'd never get a 1GB drive full, but by quantum physics. But the fact that it's maximum theoretical size has "a few reserves" isn't a problem in itself. I have serious doubts that the computers of today are ready for the overhead at all and the overhead is worth the bother. > 1) you make create 1000 of "filesystems" without partitioning. so lots of > "admins" that think more partitions=better are happy. you may set quota > for each "filesystem" Well, actually I am an admin who believes this within limits. I have seperate file systems for /, /usr, /var, /tmp, /home and /usr/obj. The reasons for this are numerous. I have /usr/obj on a different drive than /usr to spread the load while making worlds and I mount /usr/obj asynchronously to increase write speed. With several filesystems I can spread to load the way I want it and decide where the data goes. And one broken fs doesn't screw up the others in the process. I do know the drawbacks of this: Storage is pretty static. Correcting wrong estimates about the needed fs-sizes is a big problem. That is why I keep /usr/home on one big fs. If the users require (for example) 20MB each, then it doesn't matter if one user needs 25MB, as long as 5 others only use 24. If ZFS gives us the best of both worlds, that would actually be an improvement. > 2) it takes many drives to the pool and you may add then new drives. > same as gconcat+growfs. I read about this. However, I didn't find anything conclusive as to how well the drives can still live on their own if they are ever seperated. Now I don't think they will be addressed as a RAID0 with all the risks of that. But what happens if one of four drives breaks down? Does it make a difference, if the broken drive is the first one, the last one or a middle one? > 3) it doesn't have per user quota, which creates a problem that is > "solved" by 1), and you have to create at least one filesystem/user, which > then is said to relieve admininstrator from work ;) This doesn't have to be a problem either. Quota are used instead of partitions to tackle two problems: The number of partitions is very limited and resizing a partition is a major issue. By changing the quota you can give one user (or one service) more room and take it away from some of the others that seem to need less than was anticipated. If each user or service can be confined to it's own fs, that would also be good. A newsserver runnung with tradspool needs lots of inodes, most other applications far less. I do see a drawback though: If you change the size of the filesystems a few times, you could wind up with a new sort of fragmentation. New because this sort (a filesystem that is patched together over a drive) hasn't really been encountered yet and it will be very interesting to see what effects this may have. > 4) ZFS says that hardware checksums are not enough and disk hardware may > be buggy so then "solve" this problem checking everything with CPU. This also creates a lot of overhead and CPU load. I tried this with GELI on a fs that needed to be intact in a paranoid sense - I get like that sometimes. :-) I did it once and once only. The performance was just not good enough. Granted, I didn't do this on a really new computer but I'm not likely to through away all my old ones either, just so my paranoia can be met with a good speed. :-) > while i've had failing drives many times i never seen it reading bad data > and not reporting error. Same here. Since I use HDs on my computers, I have had about 20 to 25 drives break down over the years. Ok, I used many of the drives long after other people took similar drives out of their machines and used them as door stops. Basicly, I made these drives work until they dropped dead. :-) None of these drives *ever* gave strange data back. The only time I had that was when the driver for a controller was broken and that issue was there right from the beginning. > 5) you don't have to wait for fsck. one of the few real adventages. > Anyway - FreeBSD doesn't crash like windoze, so it's not that big thing. Wrong! Crashed accure and they do that quite frequently. Ev
Re: Looking for a Text on ZFS
On 03/02/2008, Christian Baer <[EMAIL PROTECTED]> wrote: > On Sat, 2 Feb 2008 21:38:49 -0600 [EMAIL PROTECTED] wrote: > > Well, the best, I think. > > I take ist, you don't approve of ZFS? :-) > It is not a panacaea. The optimisation and sharing of r/w, Load balancing, And redundant data verification (to say nothing of the supposed ability to blindly stab disks into a nearly infinite array) are all features that I can see being appreciated. In a couple of processor generations. (I am talking desktop junk here) The kids running big iron will have already decided and my feeble arguments are like sand in a badger's vagina. -- -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for a Text on ZFS
I already read that before I posted my question. Neither by this text, nor by the one in the Wikipedia could I participate in the exitement around ZFS. Ok, so it's a 128Bit FS. Big fat, hairy deal! I couldn't see that's like 64-bit soundcards that have to be "better" than 32-bit, while most of them was unable to actually get past 13-14 bit (most past 12) with it's signal to noise ratio. any advantages in using it instead of FFS (UFS), but I thought I was ZFS is "better" because: 1) you make create 1000 of "filesystems" without partitioning. so lots of "admins" that think more partitions=better are happy. you may set quota for each "filesystem" 2) it takes many drives to the pool and you may add then new drives. same as gconcat+growfs. 3) it doesn't have per user quota, which creates a problem that is "solved" by 1), and you have to create at least one filesystem/user, which then is said to relieve admininstrator from work ;) 4) ZFS says that hardware checksums are not enough and disk hardware may be buggy so then "solve" this problem checking everything with CPU. while i've had failing drives many times i never seen it reading bad data and not reporting error. 5) you don't have to wait for fsck. one of the few real adventages. Anyway - FreeBSD doesn't crash like windoze, so it's not that big thing. 6) zfs set copies= works only on writes, but scrub doesn't make a missing copy when one is failed. so the best possible adventage (setting what file to mirror, what not) is lost. 7) there is no per file encryption, while it's said it will be SOON ready. 8) ZFS is clear winner on artifical tests like creating miliion of small files and then deleting them etc.. 9) ZFS is very fast, just add more RAM and faster CPU. i would - to make more RAM and CPU power available for programs i run, not to be wasted. there was a lot of excitement here after ZFS was ported, but i think it's time too see that 20 (or more?) year old UFS is still a winner. i think some changes in UFS, like larger cylinder groups (so there won't be 1 of then on big filesystem), possibly dynamic allocation of inodes, would be good. but not critical :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for a Text on ZFS
On Sat, 2 Feb 2008 21:38:49 -0600 [EMAIL PROTECTED] wrote: > ZFS ends the microsotf monopoly over our disks. And this monopoly is founded on ... what? > ZFS begins the world as a 128bit dadaspace. > Using ZFS fixes allocations and massaging your NAS. > The inode is now the wenode. > Usaging ZFS will make everything sunnier. > Brighter too. > Making ZFS the default FS in an FScentric world ends > the pesky problems associated with legacy hardware. > Building a ZFS nonuplyindirectwenode multiply redundant > redundant filesystem makes Kate Miller-Heidke the > Well, the best, I think. I take ist, you don't approve of ZFS? :-) Regards, Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for a Text on ZFS
On Sat, 2 Feb 2008 21:11:21 +0100 Mel wrote: > If you review the "Not done" items @ http://wiki.freebsd.org/ZFS and still > are > doubting, then http://www.opensolaris.org/os/community/zfs/whatis/ describes > what the features *can* be. I got a good impression from that text what the > advantages are, but I'm too conservative to migrate myself. YMMV. I already read that before I posted my question. Neither by this text, nor by the one in the Wikipedia could I participate in the exitement around ZFS. Ok, so it's a 128Bit FS. Big fat, hairy deal! I couldn't see any advantages in using it instead of FFS (UFS), but I thought I was missing something because porting it would have been somewhat of a hassle and noone would go to all that trouble if it wasn't worth the effort. Regards, Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for a Text on ZFS
On 02/02/2008, Christian Baer <[EMAIL PROTECTED]> wrote: > Hello people! > > Can anyone give me a link to a text on ZFS that tells me why I might want > to use that instead of FFS? I don't want to start a discussion which is > better, just a comparison, as I assume that the two are not designed to do > the same things. And if possible one that is understandable to people who > don't hack FS-code. :-) http://blogs.sun.com/jonathan/entry/harvesting_from_a_troll http://zamwi.com/2007/01/16/why-do-geeks-have-lust-for-zfs/ ZFS ends the microsotf monopoly over our disks. ZFS begins the world as a 128bit dadaspace. Using ZFS fixes allocations and massaging your NAS. The inode is now the wenode. Usaging ZFS will make everything sunnier. Brighter too. Making ZFS the default FS in an FScentric world ends the pesky problems associated with legacy hardware. Building a ZFS nonuplyindirectwenode multiply redundant redundant filesystem makes Kate Miller-Heidke the Well, the best, I think. -- -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for a Text on ZFS
If you review the "Not done" items @ http://wiki.freebsd.org/ZFS and still are doubting, then http://www.opensolaris.org/os/community/zfs/whatis/ describes what the features *can* be. I got a good impression from that text what the advantages are, but I'm too conservative to migrate myself. YMMV. very good. "CAN be" isn't very useful. while ZFS provide "virtual partitions" (which may LOOK good), it doesn't work well with 2 or more pools created out of partitions not full drives. my common config on machines with >1 drive is to make gmirror (or gmirror+gstripe) from first partitions of each drive, to store most common data, usually EXCEPT huge files, and gconcat from other partitions to store mostly big files, other rarely used things, copies of other things etc. then drives seeks mostly within first partition so it's much faster, and i have unmirrored larger space on second. with ZFS it is not possible, while it CLAIMED to completely and definitely remove all these burder about planning disk layouts. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for a Text on ZFS
On Saturday 02 February 2008 20:07:50 Christian Baer wrote: > Can anyone give me a link to a text on ZFS that tells me why I might want > to use that instead of FFS? I don't want to start a discussion which is > better, just a comparison, as I assume that the two are not designed to do > the same things. And if possible one that is understandable to people who > don't hack FS-code. :-) If you review the "Not done" items @ http://wiki.freebsd.org/ZFS and still are doubting, then http://www.opensolaris.org/os/community/zfs/whatis/ describes what the features *can* be. I got a good impression from that text what the advantages are, but I'm too conservative to migrate myself. YMMV. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
