Did you seal up the cooling vents? If a router overheats trying to run sustained full rate, or in this case a mere 1/10th of full rate, I think you need to get your money back.
Does OSX not follow typical behavior of reserving the last few percent of storage for root only, specifically to prevent a computer becoming unusable because a user filled the hard drive?
Assuming you can't get the other broadcaster to cooperate, you can't broadcast with the same "quality" (as defined by resolution and frequency-of-scene-changes) as you could if you controlled the entire 6MHz channel.
There is only one broadcaster. There is only one MPEG2 transport stream, now containing both programs. They must cooperate, as they are sharing one piece of transmission gear. It's not like a cellular network where two different entities are sharing time slices of a common spectrum. Also, I'm not aware of any broadcaster that uses 1080p.
No. Charliemopps was referring to the fact that you do not subdivide your spectrum. Subchannels are separated logically, not physically. Two video streams on a 6MHz channel is two video streams on a single 6MHz channel, not two video streams each with their own 3MHz channel.
Channels don't exist on a carrier. The data stream exists on the carrier, the (MPEG2) transport stream is encoded in the data stream, and as many audio and video streams of whatever resolution you want are multiplexed into that transport stream. Only practicality limits you to two 720p60 MPEG2 video streams in a single 6MHz 8VSB band, as the compression levels needed to push further down than that on typical content starts to become very noticeable.
Old 78s and 45s were never better than digital, in any fashion. They added weight and ceremony to listening to music, because of the care needed in using them. They added distortions that people like to call "warmth". Both of these are form, and run in direct violation to their primary function as a storage medium.
I'm somewhat confused. Each ATSC channel is a fixed 6 MHz wide spectrum. They can either do one HD channel or four SD channels
There's no explicit maximum, or at least none that you could ever reasonably reach. It all comes down to how much you compress the data. You can run dozens of HD channels on a single multiplex if they look like shit, or are primarily static images.
At the end of the day, all I know is that stations which once were viewable (some even perfect) under analog are no longer viewable under digital.
That sounds like other changes were made at the same time, independent of the digital transition. Their new transmitters are cheap shit. They dropped to a lower transmit power. They moved to a different antenna or frequency that results in increased interference.
Are you sure about that? ZFS has a "copies" parameter as well. It just means it stores two copies of the block somewhere in the pool. If you give it multiple disks in a pool, it will try to place those copies on different disks, but it will not guarantee it. It's a measure to prevent data loss when you have a damaged sector, not a full disk failure.
If you have disks of different sizes with copies=2, will it refuse to write if you only have one disk with free space remaining?
In the US, if you receive something of monetary value in exchange for a service, you have received income, and that income is taxed. If Google is not being taxed on the data it receives for its free services, then the government itself is saying there is no monetary value on that data. No value means no sale, and thus no customer. Just because you have a contract does not require that one party be a customer.
The argument against allowing expansion of parity arrays is that if you find yourself wanting to add a single disk to a parity array, you didn't properly plan for expansion when you designed the system. ZFS was originally designed for enterprise customers, for whom that was not a feature that would rarely ever see use. It was not intended for the home user piecing together spare parts for a file server.
With btrfs RAID1, which is what I'm using, you throw a drive in, hit rebalance, and you now have more storage, properly mirrored with distributed metadata.
If you have RAID1 and add a drive, you still have RAID1, and just as much storage as you started with. You only add redundancy, unless you're saying it converted the mirror into a parity array.
Chances are if you're an enterprise user running enterprise Linux with a support contract, you're going to engineer in immediate needs, future expansion, and replacement when you purchase your server equipment. You're not going to throw something together and get yourself into a situation where you would need dynamic resizing of a stripe. That's more a concern for the home and small business user who may not have the funds to plan for expansion when building a server, but then that's not the market Sun was shooting for when designing ZFS.
Why would I prefer DIF on FC and SAS2 over the drive's internal ECC mechanisms? A single layer of protection means a single layer that has to fail before data loss.
The same can be said for any other filesystem as well. If you have a bad bit in memory, and you write it to disk, that data is corrupted. The only penalty under ZFS is that if you gave it redundancy, and leave checksums enabled, it will detect that fault, try to correct it, and in doing so crush the whole block instead of just one bit.
If you aren't going to use ECC memory, don't use checksums either.
While you cannot add new drives to a vdev, you can expand a vdev by incrementally replacing all of its drives with larger versions. Replace a drive, resilver, replace a drive, resilver... and when you're all done, just export the pool, import it back, and you have the full capacity of the new drives available.
In my experience it needs a lot more memory than software RAID5. Something like 1GB per TB of disk space if running RAIDZ.
It appears to use a lot of memory because it replaces the standard kernel disk cache with its own ARC, and as unused memory is wasted memory, the ARC will eat up every last bit of memory you allow it.
Scrubbing can thrash your CPU pretty good, too.
It's performing a checksum of your entire system. That's going to be a CPU hog. BTRFS will be no different in this regard. Still, the default algorithm is fairly lightweight, and on a modern multi-core multi-GHz system, you should be bottlenecked on disk long before you "thrash" your CPU. If you're trying to run ZFS on an old low end Atom, well... don't do that!
and I needed the capability to add new drives to the pool which ZFS doesn't handle gracefully.
Of course it does. It just has some limitations. You cannot remove devices from a pool, and you cannot reshape a Z/2/3 vdev. You can add a new disk to a mirror vdev. You can replace all the disks in a Z vdev with larger ones, and then expand the vdev to use the new space. You can add a new disk to a pool. You can add a new mirror or Z vdev to a pool.
If you intend to send the snapshots over the network, as is often the case with rsync, you need to pair it with some independent communication tool, and since the output of "zfs send" tends to be very bursty, you need a sizable memory buffer.
Physics can already be done on the GPU very well - the development we're waiting for is getting data back off the GPU and into main system memory fast enough for the CPU to be able to use it (ie, this stuff being used for gameplay, not just eye candy). That won't happen until there's a rethink on how GPUs are connected to the mainboard
This isn't the turn of the century with your new fangled AGP 4x graphics card. PCI Express is symmetric. You can pull data in from peripherals just as fast as you can push it out. If there is a bottleneck in pulling computed physics data from modern graphics cards, it's entirely the fault of the internal design of those modern graphics cards.
Slashdot Mirror
Did you seal up the cooling vents? If a router overheats trying to run sustained full rate, or in this case a mere 1/10th of full rate, I think you need to get your money back.
So, I'm curious what you do with your home network that you need ethernet to each room?
Use it with a bunch of stationary devices? Two-way broadcast communication should only be used for mobile devices.
So the OP is just full of shit?
Does OSX not follow typical behavior of reserving the last few percent of storage for root only, specifically to prevent a computer becoming unusable because a user filled the hard drive?
Assuming you can't get the other broadcaster to cooperate, you can't broadcast with the same "quality" (as defined by resolution and frequency-of-scene-changes) as you could if you controlled the entire 6MHz channel.
There is only one broadcaster. There is only one MPEG2 transport stream, now containing both programs. They must cooperate, as they are sharing one piece of transmission gear. It's not like a cellular network where two different entities are sharing time slices of a common spectrum. Also, I'm not aware of any broadcaster that uses 1080p.
Generally studio shows fare better because they're only 24fps with frame duplication. There's simply much less data to send.
No. Charliemopps was referring to the fact that you do not subdivide your spectrum. Subchannels are separated logically, not physically. Two video streams on a 6MHz channel is two video streams on a single 6MHz channel, not two video streams each with their own 3MHz channel.
Channels don't exist on a carrier. The data stream exists on the carrier, the (MPEG2) transport stream is encoded in the data stream, and as many audio and video streams of whatever resolution you want are multiplexed into that transport stream. Only practicality limits you to two 720p60 MPEG2 video streams in a single 6MHz 8VSB band, as the compression levels needed to push further down than that on typical content starts to become very noticeable.
78s and 45s are still better than digital.
Old 78s and 45s were never better than digital, in any fashion. They added weight and ceremony to listening to music, because of the care needed in using them. They added distortions that people like to call "warmth". Both of these are form, and run in direct violation to their primary function as a storage medium.
I'm somewhat confused. Each ATSC channel is a fixed 6 MHz wide spectrum. They can either do one HD channel or four SD channels
There's no explicit maximum, or at least none that you could ever reasonably reach. It all comes down to how much you compress the data. You can run dozens of HD channels on a single multiplex if they look like shit, or are primarily static images.
At the end of the day, all I know is that stations which once were viewable (some even perfect) under analog are no longer viewable under digital.
That sounds like other changes were made at the same time, independent of the digital transition. Their new transmitters are cheap shit. They dropped to a lower transmit power. They moved to a different antenna or frequency that results in increased interference.
Are you sure about that? ZFS has a "copies" parameter as well. It just means it stores two copies of the block somewhere in the pool. If you give it multiple disks in a pool, it will try to place those copies on different disks, but it will not guarantee it. It's a measure to prevent data loss when you have a damaged sector, not a full disk failure.
If you have disks of different sizes with copies=2, will it refuse to write if you only have one disk with free space remaining?
In the US, if you receive something of monetary value in exchange for a service, you have received income, and that income is taxed. If Google is not being taxed on the data it receives for its free services, then the government itself is saying there is no monetary value on that data. No value means no sale, and thus no customer. Just because you have a contract does not require that one party be a customer.
The argument against allowing expansion of parity arrays is that if you find yourself wanting to add a single disk to a parity array, you didn't properly plan for expansion when you designed the system. ZFS was originally designed for enterprise customers, for whom that was not a feature that would rarely ever see use. It was not intended for the home user piecing together spare parts for a file server.
With btrfs RAID1, which is what I'm using, you throw a drive in, hit rebalance, and you now have more storage, properly mirrored with distributed metadata.
If you have RAID1 and add a drive, you still have RAID1, and just as much storage as you started with. You only add redundancy, unless you're saying it converted the mirror into a parity array.
On a gigabit network with the standard 64K pipe buffer, you'll trickle along at just a few megabit.
Chances are if you're an enterprise user running enterprise Linux with a support contract, you're going to engineer in immediate needs, future expansion, and replacement when you purchase your server equipment. You're not going to throw something together and get yourself into a situation where you would need dynamic resizing of a stripe. That's more a concern for the home and small business user who may not have the funds to plan for expansion when building a server, but then that's not the market Sun was shooting for when designing ZFS.
Why would I prefer DIF on FC and SAS2 over the drive's internal ECC mechanisms? A single layer of protection means a single layer that has to fail before data loss.
The same can be said for any other filesystem as well. If you have a bad bit in memory, and you write it to disk, that data is corrupted. The only penalty under ZFS is that if you gave it redundancy, and leave checksums enabled, it will detect that fault, try to correct it, and in doing so crush the whole block instead of just one bit.
If you aren't going to use ECC memory, don't use checksums either.
So you can't expand an existing vdev
While you cannot add new drives to a vdev, you can expand a vdev by incrementally replacing all of its drives with larger versions. Replace a drive, resilver, replace a drive, resilver... and when you're all done, just export the pool, import it back, and you have the full capacity of the new drives available.
In my experience it needs a lot more memory than software RAID5. Something like 1GB per TB of disk space if running RAIDZ.
It appears to use a lot of memory because it replaces the standard kernel disk cache with its own ARC, and as unused memory is wasted memory, the ARC will eat up every last bit of memory you allow it.
Scrubbing can thrash your CPU pretty good, too.
It's performing a checksum of your entire system. That's going to be a CPU hog. BTRFS will be no different in this regard. Still, the default algorithm is fairly lightweight, and on a modern multi-core multi-GHz system, you should be bottlenecked on disk long before you "thrash" your CPU. If you're trying to run ZFS on an old low end Atom, well... don't do that!
and I needed the capability to add new drives to the pool which ZFS doesn't handle gracefully.
Of course it does. It just has some limitations. You cannot remove devices from a pool, and you cannot reshape a Z/2/3 vdev. You can add a new disk to a mirror vdev. You can replace all the disks in a Z vdev with larger ones, and then expand the vdev to use the new space. You can add a new disk to a pool. You can add a new mirror or Z vdev to a pool.
If you intend to send the snapshots over the network, as is often the case with rsync, you need to pair it with some independent communication tool, and since the output of "zfs send" tends to be very bursty, you need a sizable memory buffer.
Do you hide them behind the finished carpentry projects?
More accurately, the "exciting" choice is the inexpensive choice, and inexpensive means more launches, or more money available for other programs.
Physics can already be done on the GPU very well - the development we're waiting for is getting data back off the GPU and into main system memory fast enough for the CPU to be able to use it (ie, this stuff being used for gameplay, not just eye candy). That won't happen until there's a rethink on how GPUs are connected to the mainboard
This isn't the turn of the century with your new fangled AGP 4x graphics card. PCI Express is symmetric. You can pull data in from peripherals just as fast as you can push it out. If there is a bottleneck in pulling computed physics data from modern graphics cards, it's entirely the fault of the internal design of those modern graphics cards.