FreeBSD 7.0: ZFSv6 FreeBSD 7.1: don't recall if it was still ZFSv6 or ZFSv13 FreeBSD 7.2: ZFSv13 FreeBSD 7.3: ZFSv14 FreeBSD 7.4: should still be ZFSv14 when 7.4 is released soon-ish
FreeBSD 8.0: ZFSv14 FreeBSD 8.1: ZFSv14 FreeBSD 8.2: should have ZFSv15 when 8.2 is released soon-ish
FreeBSD 9.0: should have ZFSv28 when the 9.0 release happens in 2011
Question about ZFS, say I have a bunch of ZFS filesystems on a bunch of physical drives or drive arrays on Solaris/OpenSolaris/OpenIndiana.
How do I figure out which physical drives/devices a particular ZFS filesystem depends on?
You don't. That's the whole point of pooled storage: you stop thinking into terms of "filesystem on partition on disk" and just start thinking "filesystem on storage". ZFS filesystems are not "dependent on a single drive". You don't partition disks, you don't create filesystems on partitions, you don't worry about figuring out filesystem sizes ahead of time. You just aggregate all your storage into a single pool, and create filesystems on top. If a filesystem needs space and it's available in the pool, it uses it. Simple as that.
Hence, why you create redundant vdevs (think of them like RAID arrays) beneath the pool, so that if something does go wrong with a drive, you can easily replace it without losing data.
You make it sound like you need an extra 10 terabytes to backup a 10 terabyte volume with LVM. You don't. It takes a snapshot and the free space you need is for further changes to the volume.
How would you configure a 10 TB disk array, using LVM, such that you can keep 365 daily snapshots for a single filesystem?
With ZFS, it's simple: create the storage pool, create the filesystem, create snapshot each night. Done.
With LVM, it's a nightmare I don't want to even think about, involving creating volumes, creating filesystems, saving "unallocated" space for the snapshots, deciding how much space to reserve for each snapshot, etc, etc, etc
LVM snapshots have one purpose: creating a device that won't change that you can use as a source of backups, that is easily destroyed after the backup run is finished. *VERY* different from ZFS snapshots which are meant to be persistent, with all kinds of nice extra features LVM lacks, like snapshot roll-back, snapshot cloning, promoting snapshots to filesystems, deleting individual snapshots no matter how old they are, etc.
There's really no comparison to volume management and snapshots via LVM, and storage pool management and snapshots with ZFS.
You really should re-run the benchmarks. Depending on which version of FreeBSD 7.x, you were using either ZFSv6 (ancient and slow), ZFSv13 (faster), or ZFSv14 (faster still). Comparing ZFSv6 to anything is pointless to the extreme, except to show just how far ZFS speed has come since then.:)
On a single harddrive, you can set "copies=2" (or higher) and get multiple copies of data blocks stored in different parts of the disk. Thus, if a checksum shows corrupt data on a read, it will read one of the extra copies and save the correct data overtop of the bad data. (Btrfs has this feature as well.)
Without checksumming, how will you know that data you wrote last month is still valid and correct? Especially if the disk reads it and passes it up the chain to the filesystem? A bit flip here and there can do wonders to corrupt large multi-MB files. And there's no fsck in the world that can help to fix that.
It's all a trade-off between the features you find important. Some want raw throughput without caring about data corruption. Others want data safety above all else and can tolerate slow I/O. Others want a nice balance between them. Non-ZFS filesystems give you speed at the risk of data corruption with very few options for improving data safety. ZFS gives you options for increasing the raw I/O speed, without ever sacrificing data safety. AND, it gives you the options for removing data safety (non-redundant vdevs aka RAID0; disable checksums, disable scrubs, etc).
ext*, xfs, jfs, ufs, ntfs, hfs, etc are great, well-performing filesystems. But they are pain to manage when you get over 8 physical disks, and over 10 GB of storage. Especially if you need snapshots, compression, or dedupe, which none of these FSes support, adding more and more layers to manage.
For desktops, laptops, palmtops, etc, ZFS may be overkill.
But for servers, there's really nothing like it available for OSS.
You forgot to mention that you need to set that up in advanced as it doesn't do that by default and having to come up with settings for any given system is horribly time consuming, compared to just having a regular incremental backup operating every X hours.
ZFS does checksumming by default. It's one of the main reasons-for-being for ZFS.
Mainly in Eastern Canada. Us Westerners, at least on Shaw Cable, don't have these "caps" to worry about. And those with Telus fibre connections have 200+ GB caps. It's really only Bell and Rogers that try to screw over their customers with paltry data limits.
I work for a local school district, and we did just this. Laid out our specs, and sent it out vendors. Our current hardware is:
Slim desktop case (has 3.5" and 5.24" external bays, 3.5" internal bay) Asus motherboard (I forget the model number, but lots of USB and SATA) AMD Sempron 2.0 GHz CPU (64-bit capable) 1 GB of RAM (supports 4 GB) onboard nVidia graphics onboard HDA audio
Without a harddrive, floppy, optical drive, or OS, they're $200 CDN in groups of 30.
What are you buying that's $1000 (US I'm guessing)?? That's insane for a business desktop PC.
That's the problem with the current patent system in the States. Mathematical algorithms originally were not patentable. Software is really nothing more than mathematical algorithms. And yet, you find software patents, even purely algorithmic patents, running rampant.
First to 1 GHz. First to lose the frontside bus. First to 64-bit x86. First to true multicore (on same die). There's probably a few more. AMD has been first to a lot of neat technology.
the freebsd zfs port lags (too much to really call 'current')
FreeBSD 7.3, 8.0, and 8.1 support ZFSv14, which until around last month was the same version as Solaris.
There are patches available for FreeBSD 8-STABLE to bring it to ZFSv15, which until this week was the same version as in Solaris.
There are patches available for FreeBSD 9-CURRENT to bring it to ZFSv28, which is ahead of the ZFS version support in the most recent Solaris release (ZFSv22). This would bring it up to parity with the last version available in OpenSolaris. And there's even a super-experimental version of the patchset for 8-STABLE
I honestly fail to see how that is not "current". The plan for ZFS in FreeBSD has always been to keep it on par with Solaris, which the devs have been (until this week) successful at doing.
So, no, the kids aren't turned into zombies. On the contrary.
Depends on the meds. Putting an ADD/ADHD kid on the wrong drugs *can* turn them into lethargic zombies. I've watched it first hand with my sister and my cousin. It can take several months of trial and error to find the correct drugs, the correct dosages, and the correct timings for things to work correctly and be effective. During those months, you can go through zombie-like, super-active/manic, normal, psychotic, etc.
ZFS is also available in FreeBSD 7.0 and later. It's even marked as "production quality" in FreeBSD 8.0 and later.
It's a few versions behind (ZFSv14) OpenSolaris (ZFSv24), but on par with Solaris 10 (ZFSv15). FreeBSD 8.1 should have ZFSv15 in it by the time it's released this summer. And there's work ongoing to bring ZFSv20-something into 9.0.
The difference is that the dial-up plans weren't capped. Sure, you paid by the hour, but you could download at full 100% line usage for that entire hour, without getting throttled by the ISP. And if you wanted to do downloads 24/7 until your hours were up, you could, no questions asked. You were billed based on "number of hours connected" and nothing else.
Now, they want to bill you based on "size of the pipe into your house" *AND* "number of bytes that go through that pipe".
It's essentially double-billing.
It would be like if the dial-up ISPs of old had charged you $X for 20 hours of 56K connection *AND* $Y if you download more than 5 GB in a month.
Then they should drop the base cost (the $X per month for a Y Mbps connection) and charge *ONLY* for the number of bytes that go through the byte. Just like a utility.
When was the last time your gas/electric company charged you based on the size of the pipe/wire going into your building?
If I'm paying for a 5 Mbps connection, then why should I be penalised for using that 5 Mbps connection 24/7? I paid for it, I'll download all I want, since it's paid for.
They can either charge for a pipe (Mbps) or for usage (MBs). But they can't charge for both.
That would be like the gas company sending me a bill for "a pipe capable of X cubic cm/min" on top of charging me for using 18 GJ of gas in a month.
It doesn't work that way.
Pick one or the other: the speed of the link or the amount of bytes that goes through it.
Re:paradigm of having to restart the computer?
on
Ubuntu on a Dime
·
· Score: 1
You only have to reboot for kernel updates, and for very low-level libraries that get loaded very early in the boot process.
Video card drivers, X server updates, window manager updates, even GNOME/KDE updates don't require a reboot. Just logout, click the X menu on the login screen, and select "Restart X server". Done. Login to start using the new software.
Because most EU countries have sane consumer protection laws, where consumer rights trump corporate greed. The rest of the world can learn a lot from some EU countries.
ZFS also offers block-level dedupe support since ZFSv21. You can run it via FUSE on Linux, or natively on OpenSolaris. Hopefully, it'll also be available in FreeBSD 9.0 if not sooner (FreeBSD 7.3/8.0 have ZFSv14).
Since ZFS already checksums every block that hits the disk, dedupe is almost free, as those checksums are re-used for finding/tracking duplicate blocks.
Slashdot Mirror
FreeBSD 7.0: ZFSv6
FreeBSD 7.1: don't recall if it was still ZFSv6 or ZFSv13
FreeBSD 7.2: ZFSv13
FreeBSD 7.3: ZFSv14
FreeBSD 7.4: should still be ZFSv14 when 7.4 is released soon-ish
FreeBSD 8.0: ZFSv14
FreeBSD 8.1: ZFSv14
FreeBSD 8.2: should have ZFSv15 when 8.2 is released soon-ish
FreeBSD 9.0: should have ZFSv28 when the 9.0 release happens in 2011
You don't. That's the whole point of pooled storage: you stop thinking into terms of "filesystem on partition on disk" and just start thinking "filesystem on storage". ZFS filesystems are not "dependent on a single drive". You don't partition disks, you don't create filesystems on partitions, you don't worry about figuring out filesystem sizes ahead of time. You just aggregate all your storage into a single pool, and create filesystems on top. If a filesystem needs space and it's available in the pool, it uses it. Simple as that.
Hence, why you create redundant vdevs (think of them like RAID arrays) beneath the pool, so that if something does go wrong with a drive, you can easily replace it without losing data.
How would you configure a 10 TB disk array, using LVM, such that you can keep 365 daily snapshots for a single filesystem?
With ZFS, it's simple: create the storage pool, create the filesystem, create snapshot each night. Done.
With LVM, it's a nightmare I don't want to even think about, involving creating volumes, creating filesystems, saving "unallocated" space for the snapshots, deciding how much space to reserve for each snapshot, etc, etc, etc
LVM snapshots have one purpose: creating a device that won't change that you can use as a source of backups, that is easily destroyed after the backup run is finished. *VERY* different from ZFS snapshots which are meant to be persistent, with all kinds of nice extra features LVM lacks, like snapshot roll-back, snapshot cloning, promoting snapshots to filesystems, deleting individual snapshots no matter how old they are, etc.
There's really no comparison to volume management and snapshots via LVM, and storage pool management and snapshots with ZFS.
You really should re-run the benchmarks. Depending on which version of FreeBSD 7.x, you were using either ZFSv6 (ancient and slow), ZFSv13 (faster), or ZFSv14 (faster still). Comparing ZFSv6 to anything is pointless to the extreme, except to show just how far ZFS speed has come since then. :)
On a single harddrive, you can set "copies=2" (or higher) and get multiple copies of data blocks stored in different parts of the disk. Thus, if a checksum shows corrupt data on a read, it will read one of the extra copies and save the correct data overtop of the bad data. (Btrfs has this feature as well.)
Without checksumming, how will you know that data you wrote last month is still valid and correct? Especially if the disk reads it and passes it up the chain to the filesystem? A bit flip here and there can do wonders to corrupt large multi-MB files. And there's no fsck in the world that can help to fix that.
It's all a trade-off between the features you find important. Some want raw throughput without caring about data corruption. Others want data safety above all else and can tolerate slow I/O. Others want a nice balance between them. Non-ZFS filesystems give you speed at the risk of data corruption with very few options for improving data safety. ZFS gives you options for increasing the raw I/O speed, without ever sacrificing data safety. AND, it gives you the options for removing data safety (non-redundant vdevs aka RAID0; disable checksums, disable scrubs, etc).
ext*, xfs, jfs, ufs, ntfs, hfs, etc are great, well-performing filesystems. But they are pain to manage when you get over 8 physical disks, and over 10 GB of storage. Especially if you need snapshots, compression, or dedupe, which none of these FSes support, adding more and more layers to manage.
For desktops, laptops, palmtops, etc, ZFS may be overkill.
But for servers, there's really nothing like it available for OSS.
ZFS does checksumming by default. It's one of the main reasons-for-being for ZFS.
You can manually turn it off, though.
Mainly in Eastern Canada. Us Westerners, at least on Shaw Cable, don't have these "caps" to worry about. And those with Telus fibre connections have 200+ GB caps. It's really only Bell and Rogers that try to screw over their customers with paltry data limits.
Shouldn't the family of the deceased be suing the parents of the 4-year old, and not the 4-year old directly?
I work for a local school district, and we did just this. Laid out our specs, and sent it out vendors. Our current hardware is:
Slim desktop case (has 3.5" and 5.24" external bays, 3.5" internal bay)
Asus motherboard (I forget the model number, but lots of USB and SATA)
AMD Sempron 2.0 GHz CPU (64-bit capable)
1 GB of RAM (supports 4 GB)
onboard nVidia graphics
onboard HDA audio
Without a harddrive, floppy, optical drive, or OS, they're $200 CDN in groups of 30.
What are you buying that's $1000 (US I'm guessing)?? That's insane for a business desktop PC.
That's the problem with the current patent system in the States. Mathematical algorithms originally were not patentable. Software is really nothing more than mathematical algorithms. And yet, you find software patents, even purely algorithmic patents, running rampant.
AMD did a 486DX4 133 MHz CPU. That was my first PC. :)
First to 1 GHz. First to lose the frontside bus. First to 64-bit x86. First to true multicore (on same die). There's probably a few more. AMD has been first to a lot of neat technology.
FreeBSD 7.3, 8.0, and 8.1 support ZFSv14, which until around last month was the same version as Solaris.
There are patches available for FreeBSD 8-STABLE to bring it to ZFSv15, which until this week was the same version as in Solaris.
There are patches available for FreeBSD 9-CURRENT to bring it to ZFSv28, which is ahead of the ZFS version support in the most recent Solaris release (ZFSv22). This would bring it up to parity with the last version available in OpenSolaris. And there's even a super-experimental version of the patchset for 8-STABLE
I honestly fail to see how that is not "current". The plan for ZFS in FreeBSD has always been to keep it on par with Solaris, which the devs have been (until this week) successful at doing.
I think both you and the OP have misread the quote, as what you just said is exactly what the student said.
I believe you and the OP misread the "a" as "no" in the quote from the student.
Otherwise, you are both agreeing with the student, by arguing against them?
Colour laser printers are under $200, and the toner cartridges last a hell of a long time. Why is anyone buying ink-based printers?
Depends on the meds. Putting an ADD/ADHD kid on the wrong drugs *can* turn them into lethargic zombies. I've watched it first hand with my sister and my cousin. It can take several months of trial and error to find the correct drugs, the correct dosages, and the correct timings for things to work correctly and be effective. During those months, you can go through zombie-like, super-active/manic, normal, psychotic, etc.
As with everything in life, it all depends.
Which includes native support for ZFS, along with a zfs-utils package to go along with it.
ZFS is also available in FreeBSD 7.0 and later. It's even marked as "production quality" in FreeBSD 8.0 and later.
It's a few versions behind (ZFSv14) OpenSolaris (ZFSv24), but on par with Solaris 10 (ZFSv15). FreeBSD 8.1 should have ZFSv15 in it by the time it's released this summer. And there's work ongoing to bring ZFSv20-something into 9.0.
Either a data rate (X Mbps), or a data quantity (Y GB/month). But definitely not both.
The difference is that the dial-up plans weren't capped. Sure, you paid by the hour, but you could download at full 100% line usage for that entire hour, without getting throttled by the ISP. And if you wanted to do downloads 24/7 until your hours were up, you could, no questions asked. You were billed based on "number of hours connected" and nothing else.
Now, they want to bill you based on "size of the pipe into your house" *AND* "number of bytes that go through that pipe".
It's essentially double-billing.
It would be like if the dial-up ISPs of old had charged you $X for 20 hours of 56K connection *AND* $Y if you download more than 5 GB in a month.
Then they should drop the base cost (the $X per month for a Y Mbps connection) and charge *ONLY* for the number of bytes that go through the byte. Just like a utility.
When was the last time your gas/electric company charged you based on the size of the pipe/wire going into your building?
If I'm paying for a 5 Mbps connection, then why should I be penalised for using that 5 Mbps connection 24/7? I paid for it, I'll download all I want, since it's paid for.
They can either charge for a pipe (Mbps) or for usage (MBs). But they can't charge for both.
That would be like the gas company sending me a bill for "a pipe capable of X cubic cm/min" on top of charging me for using 18 GJ of gas in a month.
It doesn't work that way.
Pick one or the other: the speed of the link or the amount of bytes that goes through it.
You only have to reboot for kernel updates, and for very low-level libraries that get loaded very early in the boot process.
Video card drivers, X server updates, window manager updates, even GNOME/KDE updates don't require a reboot. Just logout, click the X menu on the login screen, and select "Restart X server". Done. Login to start using the new software.
Because most EU countries have sane consumer protection laws, where consumer rights trump corporate greed. The rest of the world can learn a lot from some EU countries.
ZFS also offers block-level dedupe support since ZFSv21. You can run it via FUSE on Linux, or natively on OpenSolaris. Hopefully, it'll also be available in FreeBSD 9.0 if not sooner (FreeBSD 7.3/8.0 have ZFSv14).
Since ZFS already checksums every block that hits the disk, dedupe is almost free, as those checksums are re-used for finding/tracking duplicate blocks.