That's the strange part, it was an aviation engine.
What was it? Just out of curiosity.
Anyway, all I can say is I've never seen a warmup requirement in the operating manual of any turbine engine-powered aircraft, but maybe it's because the operational procedures were designed such that it's averted. Warmup is definitely required in piston aircraft (e.g. DA-40; after startup 2 mins idle, then 1200 rpm until oil in green; no takeoff before that). However, in-flight restart procedures don't mention warmup either. You can shut down an engine in flight, leave it off for as long as you like, restart it again and immediately apply full power. One would think if component temps were an issue that the designers of the procedure would warn about it, but apparently they don't. I don't know about industrial applications. I've seen an engine overhaul tech once mention that when they test out industrial engines they do run them up slowly, but that it's not really required.
Still not a good idea to run up to full power before ensuring that every surface is lubricated.
Curiously enough, since in turbine engines there's no sliding of surfaces going on (everything is on ball and roller bearings), oil is primarily used as coolant, not as lubrication. That's why it's okay to let a turbine engine freewheel in the wind on the ground. You won't see that happening with turboprops or helicopter rotors because these guys are using a gearbox between the engine and the prop/rotor (and a pretty aggressive one at that, usually in about a 10:1 ratio). In fact, first thing after parking you'll often see ground crew running up to tie the props and rotor down.
It's possible you're not running an aviation-derived engine design such as an LM1500 or LM2500, but instead some bespoke design for industrial turbine engines. I've never seen a warmup requirement on an aviation engine.
Actually turbine engines tend to require next to no warmup. Unlike piston engines, turbine engines don't have large blocks.
At least, this is what I've been told by turbine engine technicians and it's been reinforced by never seeing an "engine warmup" requirement in any AFM or operational procedure. For piston engines, warmup is always built into the after start procedure (or equivalent).
Less sexy would be to develop a tug that could not only push the plane back, but also perform taxi duties.
This is already done. The pushback tugs are also used for repositioning aircraft between gates and/or hangars. There are many reasons why aircraft start their engines at the gate. This serves primarily as a checkout of the aircraft systems. If an engine behaves oddly, or has trouble starting, pulling back into a gate is simple. Doing it at the runway would be a lot more complicated, as it would require a full back-taxi, which on congested airports is already a major PITA.
In addition, many of the internal systems such as flight control hydraulics are powered by the engines, so for example you won't have all flight controls fully functional (meaning, you can't perform a F/CTL check) and you can't fully extend flaps for takeoff unless you have at least one of the engine-driven pumps running. Secondly, the air conditioning packs inside the cabin are engine-powered and they take a lot of juice as well as compressed air (or you'd have to carry a sizable battery just to keep them running for the 20-30 minutes on the ground).
On very long taxis to takeoff or after landing, many aircraft already do reduced-engine taxi. 747s routinely shut down 1 or 2 engines right after landing. Twins routinely do single-engine taxi. When there is a long queue for takeoff, similarly, engines get shut down. But doing the whole taxi completely shut down and only starting once close to lining up would probably result in tons of operational complications and possibly safety issues.
Deicing doesn't deal with snow, or, well, not of the light fluffy kind anyway. It's mean to remove thick layers of solid ice that can form on surfaces and significantly affect aircraft performance. The reason for deicing when you see snow on the aircraft is because you can never be sure that there isn't at least part ice underneath it. That's why they deice, just to be sure. I'm sure you'll rather sit through an unnecessary deice 1000 times over than die once when it was really needed. Ice is no joke and people absolutely have died in aircraft because of it.
That having been said, the way it works is that they have types of deicing fluid, each of which is certified for a particular temperature and protection time. So something like up to 15 minutes of protection at -10C, 10 minutes of protection at -15C and 5 minutes of protection at -20C. The aircraft then has that allowable time window to line up and get airborne. In flight, it'll then either have to fully rely on its own anti-icing equipment, or exit the icing conditions (which usually happens fairly quickly).
The reason why we don't use an aircraft's own anti-icing equipment on the ground is because it isn't very extensive. It usually only protects critical components (typically wing leading edges, engine inlets/props and the main cockpit windshield panels plus some external sensors such as pitot-static tubes and AoA vanes) and may not be even be available for performance-critical phases of flight (such as takeoff), because it robs too much power. Adding more anti-icing equipment would add lots of weight and cost, not to mention power demand. *That's* why we thoroughly de-ice on the ground. Give the whole aircraft a good rinse, takeoff and quickly leave the icing conditions.
Don't know about biofuels, but there are proposals and some development work going on along these lines which actually do help the fleet. The reason for that is simple: you know which is the most valuable and important ship in the fleet? The aircraft carrier? The guided missile cruisers? The landing craft? Nope, it's the ugly, lowly oiler. Unless these ships are successful in their mission, the entire fancy multi-billion dollar fleet grinds to a halt within a week. You don't see spots on them being promoted in military advertising, but the oiler is really the centerpiece. When the fleet is out, all the oiler does is continuously hop around the carrier battle group while everybody sucks on its pipe like a total addict. And once the oiler is out, it's in a mad dash to the nearest middle eastern port for a refill and a mad dash back to the fleet. Without a continuous supply of fuel (and the fleet goes through *lots* of it), all your carrier escort ships stop and all flight activity stops. Essentially, at that point the fleet is useless, a victory to the enemy without a single shot fired.
So the new idea is at least partially solving this problem by synthesizing fuels directly in deployment. The carrier has plenty of nuclear power. At the very least, in theory, this can be used to synthesize jet fuel and keep the air superiority. This could help significantly lower the burden on the supply line to the fleet and thus increase the fleet's combat effectiveness. Current problems involve cost, buying fossil fuels is just too cheap. But it will not remain so forever.
Not quite zfs needs to contact the destination zfs fs to compare with the last snapshot
Ehm, no, sorry. No communication with the destination machine is required while generating an incremental send stream. How can I claim this? Well besides being quite intimate with the ZFS source base (and I can point you to the relevant source files if you so desire), just a quick read through the zfs(1M) manpage will mention this example:
As you are no doubt aware, pipes are by definition unidirectional. There is no way the zfs receive can talk to the zfs send at all. Another way to verify this is to check out ZFS backup systems such as Zetaback, which by default store the ZFS send streams as files on a central server (which may or may not actually support ZFS - it's not actually required). Now if an incremental send stream is stored as a file and then at some later point restored, this clearly tells you that there can't be any bidirectional exchange of information going on.
ZFS has metadata that permits detecting these sort of files
Side note for your entertainment in case it interests you, the way ZFS actually handles the rename case has nothing to do with trying to follow file name changes. In fact, in order to handle a rename, we don't need to look at the file being renamed at all. The trick is in the fact that directories are files too (albeit special ones) with a defined hash-table structure. ZFS send simply picks up the changes to the respective directories as if they were regular files and transfers those. The changed blocks then contain the updated name-to-inode# mappings, which is what a rename really is. From ZFS send's point of view, a filesystem is just a flat collection of objects and all it does is transfer the changes to these objects that happened between two transaction groups.
If you read on a bit in the article, you'll come across the example of daily syncing of VM images across to a backup node. While ZFS send is done in less than an hour, rsync would take north of 7 hours just to read in the local state of the VM image, much less figure out what has changed and send the diffs. This is based entirely on ZFS send's unidirectionality. The critical difference is that rsync needs to trawl the entire local dataset state completely and compare notes with the other box (which also needs to read it all in) in order to figure out what's changed. ZFS send doesn't need to do that.
The crucial difference is ZFS send is unidirectional and as such is not affected by link latency. rsync needs to go back-and-forth, comparing notes with the other end all the time. ZFS send is also a lot faster and more efficient, eliminating entire large portions of the filesystem tree structure that haven't changed without having to read them in. This is not to say that rsync's authors were any less competent coders. ZFS simply has more information available about the filesystem than rsync, so it can make smarter decisions.
Even in a transport category aircraft, I'm sure the pilot can pull the right breakers if he wants to go invisible.
At present they can. We'll see about the evolution of the ATS. Maybe in the future as SSR is further reduced and self-reporting becomes more well tested, things such ADS-B might become mandatory always-on features and we'll see battery-powered kits installed into aircraft that cannot be switched off.
I'm not sure that ADS-B was really designed with anti-hacking in mind. It seems to be designed to work as long as everybody is playing nicely.
All of ATS is traditionally very much a gentlemen's club. There's nothing stopping you from hopping into your nearest non-transpondered non-radioed Supercub and generally behaving like an ass in the air. Same as on the roads, this kind of fun ends only when the guys with the big guns arrive.
You are not a pilot. That much is plainly obvious from your comment, although you seem to know just enough about aviation and ATC that you managed to confuse yourself.
How do you propose that "precautions" are taken in instrument flight conditions?
All flights performed in IMC must be according to IFR and are hence controlled flights.
Aircraft only have weather radar and can't see other aircraft on it so they rely on ATC.
Which is exactly why uncontrolled flights are not allowed in IMC.
Apart from across the oceans aircraft do not fly in areas without radar coverage
I guess you've never heard about procedural control. Most small-to-mid sized airports around the world do not have radar. The bigger problem is you seem to have no idea about the hierarchy of ATS. Pilots don't just "talk to the tower". And even IFR flights are not required to receive radar services.
Also were you away on Mars or something when MH370 disappeared taking 200 people with it.
I guess you didn't know either that the disabling of MH370s transponder wasn't the real problem. It was still on military tracking radars for a while. The problem was that they *left* radar coverage and went out over the ocean. Or are you one of those conspiracy nuts who thinks they landed somewhere in Kazakhstan or were abducted by aliens?
The civilian ATS (Air Traffic Service) is not designed to deal with openly hostile aircraft. That's what the Air Force is for.
Also, SSR isn't anywhere near sensitive enough to resolve small objects like drones. I know most people in the public at large think the national airspace is tightly controlled, but it really isn't like that. The highly controlled parts (e.g. in the vicinity of major airports) are the significant minority. Even places you might think of are tightly regulated (e.g. over most cities with the notable exception of Washington DC) are actually open to anybody taking pretty much anything and flying around with it (on paper you and your aircraft should be properly licensed, but you're not gonna get pulled over in the air by anybody to check).
I'm trying to talk simple language here to people who are not into aviation. I'm not trying to imply you can't switch it off for nefarious purposes. Btw: SSR wouldn't help you much there either. You see a blip on the radar that doesn't communicate with you and doesn't give ID or altitude. Good job. What now? You are not the air force. Your job is not to secure the border. If you have security concerns you call the people who have the equipment that doesn't care if the target cooperates. You'd do exactly the same in case of lost contact on a passive system ala ADS-B Out.
I should have qualified that a bit:
1) I was trying to primarily address large transport aircraft and issues of flight safety.
2) I'm NOT trying to address attempts at tampering.
Obviously as soon as you start pulling breakers, we're well past the accidental disconnection stage. SSR wouldn't help you here much either from the POV of ATC. What would you expect ATC to do with it if an aircraft intentionally disables the transponder? Fire missiles at the uncooperative aircraft? They have buddies wearing green who are far better equipped at talking sense into people looking to cause trouble. Moreover, as I mentioned, SSR will be retained where traffic density requires it. ADS-B Out makes sense in places where providing radar coverage is uneconomical and more-or-less unnecessary.
I know you were trying to be snarky, but you did accidentally ask a good question where the answer isn't trivial:
Since the dawn of radar ATC, civilian radar has been SSR - Secondary Surveillance Radar, meaning, it requires cooperation from the aircraft. SSR gives you the horizontal location of the target, but not its elevation. Instead, together with the actual radar return, the aircraft responds using a short digital code that identifies it and tells you its altitude (as read from the onboard altimeter by the SSR equipment on the aircraft). SSR has numerous advantages over PSR, mainly its not as complex, doesn't require as much power and has greater range, all of which are useful in a civilian environment. Also, it has no military application, so it carries far fewer export concerns.
Even so, SSR is still very expensive and providing good coverage is difficult to impossible. Even modern industrialized countries such as the USA have many places where radar coverage is simply unavailable (especially at lower altitudes). In less well of places, such as large areas of Africa, radar coverage is nonexistent.
The vast majority of all aircraft (and nearly all commercial aircraft) have some sort of navigational equipment that is completely independent of radar coverage and is reasonably accurate to provide traffic separation services. Put simply, aircraft are able to navigate without any ground assistance.
And so the natural evolution is to largely abandon SSR (except for areas of extremely high traffic density) and instead place around the country only small receiver stations that listen to aircraft position reports. Using those then, ATC can build a complete traffic picture and provide separation services without having to maintain expensive ground equipment.
While you are correct that ZFS/w raid-z doesn't have a write hole problem, you got the reasons for it a little wrong, so consider these just helpful tips from a ZFS developer. The real trick with raid-z is ZFS' COW nature combined with the fact that all writes a full-stripe writes (variable stripe size). Alternatively, you could say that ZFS doesn't really have anything like a stripe, but instead has a variable block component distribution map which depends on the block's location and size. Here's the actual code that does the raid-z map computation.
RAID5 has n data disks plus one dedicated parity-only disk; ZFS distributes all data and all parity across all disks
RAID-5 also spreads parity among all component disks. Each stripe, the parity disk is switched. This is done to achieve higher throughput on reads, as without it, one disk would always sit idle for read workloads.
ZFS updates metadata before data
Actually, ZFS updates metadata together with user data, but the trick is that the update is never performed in place. So what happens is that we write user data along with nearly all the metadata needed to access it. Then, once everything has finished writing (and has been sync'ed to stable storage), we update the root block pointers to point to the new metadata tree and again, sync those. In this respect ZFS is much more like an ACID-compliant database than just a conventional filesystem.
If anybody could sue Canonical for shipping ZFS in Ubuntu, it couldn't be Oracle, because the CDDL doesn't prohibit combining CDDL'd code with other licenses, provided the CDDL'd bits remain CDDL and that you distribute them to your users. It's the GPL that prohibits these combos - hence the "infectious license" moniker. So it'd have to be Linux copyright holders suing Canonical (oh the irony) for presumably combining the GPL'd Linux kernel with the CDDL'd ZFS code. Seeing as nothing like this has yet happened even with Canonical distributing the much more egregious Nvidia binary blob, I think the entire notion of this being a real legal hurdle is nothing but GPL-purist FUD.
The write hole in btrfs is AFIAK also present in zfs and listed as a risk of a power failure during write on a raid pool with COW filesystems.
The problem you describe makes no sense in ZFS. ZFS never overwrites in-place and a synchronous write is not acknowledged until all component devices (including parity) have sync'ed to stable storage. ZFS will never ever try to read a partially written stripe block (simply because it has no pointers to it yet). After a synchronous write (O_SYNC) returns, it is guaranteed to have all of its data available, regardless if it was overwriting a portion of a file in place, or appending new data to a file.
I think you're misunderstanding how raid-z actually works. raid-z is kinda like RAID-5, but not completely and it's this difference that allows ZFS to not have a write hole at all. All writes to a raid-z, regardless of size, are "full-stripe". The key in ZFS is that there is no fixed stripe size. I'd recommend Jeff Bonwick's original article on raid-z for a writeup of the principles and Matt Ahrens' article ZFS RAIDZ stripe width, or: How I Learned to Stop Worrying and Love RAIDZ for a nice diagram illustrating the layout.
Slashdot Mirror
That's the strange part, it was an aviation engine.
What was it? Just out of curiosity.
Anyway, all I can say is I've never seen a warmup requirement in the operating manual of any turbine engine-powered aircraft, but maybe it's because the operational procedures were designed such that it's averted. Warmup is definitely required in piston aircraft (e.g. DA-40; after startup 2 mins idle, then 1200 rpm until oil in green; no takeoff before that). However, in-flight restart procedures don't mention warmup either. You can shut down an engine in flight, leave it off for as long as you like, restart it again and immediately apply full power. One would think if component temps were an issue that the designers of the procedure would warn about it, but apparently they don't. I don't know about industrial applications. I've seen an engine overhaul tech once mention that when they test out industrial engines they do run them up slowly, but that it's not really required.
Still not a good idea to run up to full power before ensuring that every surface is lubricated.
Curiously enough, since in turbine engines there's no sliding of surfaces going on (everything is on ball and roller bearings), oil is primarily used as coolant, not as lubrication. That's why it's okay to let a turbine engine freewheel in the wind on the ground. You won't see that happening with turboprops or helicopter rotors because these guys are using a gearbox between the engine and the prop/rotor (and a pretty aggressive one at that, usually in about a 10:1 ratio). In fact, first thing after parking you'll often see ground crew running up to tie the props and rotor down.
It's possible you're not running an aviation-derived engine design such as an LM1500 or LM2500, but instead some bespoke design for industrial turbine engines. I've never seen a warmup requirement on an aviation engine.
high density users (more than 250kW per square foot)
Holy shit! That sort of power density puts a nuclear power plant to shame. Or has some journalist again mixed up their units?
Actually turbine engines tend to require next to no warmup. Unlike piston engines, turbine engines don't have large blocks.
At least, this is what I've been told by turbine engine technicians and it's been reinforced by never seeing an "engine warmup" requirement in any AFM or operational procedure. For piston engines, warmup is always built into the after start procedure (or equivalent).
Less sexy would be to develop a tug that could not only push the plane back, but also perform taxi duties.
This is already done. The pushback tugs are also used for repositioning aircraft between gates and/or hangars. There are many reasons why aircraft start their engines at the gate. This serves primarily as a checkout of the aircraft systems. If an engine behaves oddly, or has trouble starting, pulling back into a gate is simple. Doing it at the runway would be a lot more complicated, as it would require a full back-taxi, which on congested airports is already a major PITA. In addition, many of the internal systems such as flight control hydraulics are powered by the engines, so for example you won't have all flight controls fully functional (meaning, you can't perform a F/CTL check) and you can't fully extend flaps for takeoff unless you have at least one of the engine-driven pumps running. Secondly, the air conditioning packs inside the cabin are engine-powered and they take a lot of juice as well as compressed air (or you'd have to carry a sizable battery just to keep them running for the 20-30 minutes on the ground). On very long taxis to takeoff or after landing, many aircraft already do reduced-engine taxi. 747s routinely shut down 1 or 2 engines right after landing. Twins routinely do single-engine taxi. When there is a long queue for takeoff, similarly, engines get shut down. But doing the whole taxi completely shut down and only starting once close to lining up would probably result in tons of operational complications and possibly safety issues.
Deicing doesn't deal with snow, or, well, not of the light fluffy kind anyway. It's mean to remove thick layers of solid ice that can form on surfaces and significantly affect aircraft performance. The reason for deicing when you see snow on the aircraft is because you can never be sure that there isn't at least part ice underneath it. That's why they deice, just to be sure. I'm sure you'll rather sit through an unnecessary deice 1000 times over than die once when it was really needed. Ice is no joke and people absolutely have died in aircraft because of it.
That having been said, the way it works is that they have types of deicing fluid, each of which is certified for a particular temperature and protection time. So something like up to 15 minutes of protection at -10C, 10 minutes of protection at -15C and 5 minutes of protection at -20C. The aircraft then has that allowable time window to line up and get airborne. In flight, it'll then either have to fully rely on its own anti-icing equipment, or exit the icing conditions (which usually happens fairly quickly).
The reason why we don't use an aircraft's own anti-icing equipment on the ground is because it isn't very extensive. It usually only protects critical components (typically wing leading edges, engine inlets/props and the main cockpit windshield panels plus some external sensors such as pitot-static tubes and AoA vanes) and may not be even be available for performance-critical phases of flight (such as takeoff), because it robs too much power. Adding more anti-icing equipment would add lots of weight and cost, not to mention power demand. *That's* why we thoroughly de-ice on the ground. Give the whole aircraft a good rinse, takeoff and quickly leave the icing conditions.
Maybe have a look at the links I provided before you comment? Your question is answered there.
Don't know about biofuels, but there are proposals and some development work going on along these lines which actually do help the fleet. The reason for that is simple: you know which is the most valuable and important ship in the fleet? The aircraft carrier? The guided missile cruisers? The landing craft? Nope, it's the ugly, lowly oiler. Unless these ships are successful in their mission, the entire fancy multi-billion dollar fleet grinds to a halt within a week. You don't see spots on them being promoted in military advertising, but the oiler is really the centerpiece. When the fleet is out, all the oiler does is continuously hop around the carrier battle group while everybody sucks on its pipe like a total addict. And once the oiler is out, it's in a mad dash to the nearest middle eastern port for a refill and a mad dash back to the fleet. Without a continuous supply of fuel (and the fleet goes through *lots* of it), all your carrier escort ships stop and all flight activity stops. Essentially, at that point the fleet is useless, a victory to the enemy without a single shot fired.
So the new idea is at least partially solving this problem by synthesizing fuels directly in deployment. The carrier has plenty of nuclear power. At the very least, in theory, this can be used to synthesize jet fuel and keep the air superiority. This could help significantly lower the burden on the supply line to the fleet and thus increase the fleet's combat effectiveness. Current problems involve cost, buying fossil fuels is just too cheap. But it will not remain so forever.
My pleasure.
Not quite zfs needs to contact the destination zfs fs to compare with the last snapshot
Ehm, no, sorry. No communication with the destination machine is required while generating an incremental send stream. How can I claim this? Well besides being quite intimate with the ZFS source base (and I can point you to the relevant source files if you so desire), just a quick read through the zfs(1M) manpage will mention this example:
# zfs send pool/fs@a | ssh host zfs receive poolB/received/fs@a
As you are no doubt aware, pipes are by definition unidirectional. There is no way the zfs receive can talk to the zfs send at all. Another way to verify this is to check out ZFS backup systems such as Zetaback, which by default store the ZFS send streams as files on a central server (which may or may not actually support ZFS - it's not actually required). Now if an incremental send stream is stored as a file and then at some later point restored, this clearly tells you that there can't be any bidirectional exchange of information going on.
ZFS has metadata that permits detecting these sort of files
Side note for your entertainment in case it interests you, the way ZFS actually handles the rename case has nothing to do with trying to follow file name changes. In fact, in order to handle a rename, we don't need to look at the file being renamed at all. The trick is in the fact that directories are files too (albeit special ones) with a defined hash-table structure. ZFS send simply picks up the changes to the respective directories as if they were regular files and transfers those. The changed blocks then contain the updated name-to-inode# mappings, which is what a rename really is. From ZFS send's point of view, a filesystem is just a flat collection of objects and all it does is transfer the changes to these objects that happened between two transaction groups.
If you read on a bit in the article, you'll come across the example of daily syncing of VM images across to a backup node. While ZFS send is done in less than an hour, rsync would take north of 7 hours just to read in the local state of the VM image, much less figure out what has changed and send the diffs. This is based entirely on ZFS send's unidirectionality. The critical difference is that rsync needs to trawl the entire local dataset state completely and compare notes with the other box (which also needs to read it all in) in order to figure out what's changed. ZFS send doesn't need to do that.
The crucial difference is ZFS send is unidirectional and as such is not affected by link latency. rsync needs to go back-and-forth, comparing notes with the other end all the time. ZFS send is also a lot faster and more efficient, eliminating entire large portions of the filesystem tree structure that haven't changed without having to read them in. This is not to say that rsync's authors were any less competent coders. ZFS simply has more information available about the filesystem than rsync, so it can make smarter decisions.
Ok, fair enough.
My bad sir. I should have been more clear.
Even in a transport category aircraft, I'm sure the pilot can pull the right breakers if he wants to go invisible.
At present they can. We'll see about the evolution of the ATS. Maybe in the future as SSR is further reduced and self-reporting becomes more well tested, things such ADS-B might become mandatory always-on features and we'll see battery-powered kits installed into aircraft that cannot be switched off.
I'm not sure that ADS-B was really designed with anti-hacking in mind. It seems to be designed to work as long as everybody is playing nicely.
All of ATS is traditionally very much a gentlemen's club. There's nothing stopping you from hopping into your nearest non-transpondered non-radioed Supercub and generally behaving like an ass in the air. Same as on the roads, this kind of fun ends only when the guys with the big guns arrive.
How do you propose that "precautions" are taken in instrument flight conditions?
All flights performed in IMC must be according to IFR and are hence controlled flights.
Aircraft only have weather radar and can't see other aircraft on it so they rely on ATC.
Which is exactly why uncontrolled flights are not allowed in IMC.
Apart from across the oceans aircraft do not fly in areas without radar coverage
I guess you've never heard about procedural control. Most small-to-mid sized airports around the world do not have radar. The bigger problem is you seem to have no idea about the hierarchy of ATS. Pilots don't just "talk to the tower". And even IFR flights are not required to receive radar services.
Also were you away on Mars or something when MH370 disappeared taking 200 people with it.
I guess you didn't know either that the disabling of MH370s transponder wasn't the real problem. It was still on military tracking radars for a while. The problem was that they *left* radar coverage and went out over the ocean. Or are you one of those conspiracy nuts who thinks they landed somewhere in Kazakhstan or were abducted by aliens?
The civilian ATS (Air Traffic Service) is not designed to deal with openly hostile aircraft. That's what the Air Force is for. Also, SSR isn't anywhere near sensitive enough to resolve small objects like drones. I know most people in the public at large think the national airspace is tightly controlled, but it really isn't like that. The highly controlled parts (e.g. in the vicinity of major airports) are the significant minority. Even places you might think of are tightly regulated (e.g. over most cities with the notable exception of Washington DC) are actually open to anybody taking pretty much anything and flying around with it (on paper you and your aircraft should be properly licensed, but you're not gonna get pulled over in the air by anybody to check).
I'm trying to talk simple language here to people who are not into aviation. I'm not trying to imply you can't switch it off for nefarious purposes. Btw: SSR wouldn't help you much there either. You see a blip on the radar that doesn't communicate with you and doesn't give ID or altitude. Good job. What now? You are not the air force. Your job is not to secure the border. If you have security concerns you call the people who have the equipment that doesn't care if the target cooperates. You'd do exactly the same in case of lost contact on a passive system ala ADS-B Out.
I should have qualified that a bit:
1) I was trying to primarily address large transport aircraft and issues of flight safety.
2) I'm NOT trying to address attempts at tampering.
Obviously as soon as you start pulling breakers, we're well past the accidental disconnection stage. SSR wouldn't help you here much either from the POV of ATC. What would you expect ATC to do with it if an aircraft intentionally disables the transponder? Fire missiles at the uncooperative aircraft? They have buddies wearing green who are far better equipped at talking sense into people looking to cause trouble. Moreover, as I mentioned, SSR will be retained where traffic density requires it. ADS-B Out makes sense in places where providing radar coverage is uneconomical and more-or-less unnecessary.
ADS-B Out, which is the system I'm talking about, cannot be switched off. It becomes active as soon as the avionics stack is powered up.
And so the natural evolution is to largely abandon SSR (except for areas of extremely high traffic density) and instead place around the country only small receiver stations that listen to aircraft position reports. Using those then, ATC can build a complete traffic picture and provide separation services without having to maintain expensive ground equipment.
Glad I could help.
RAID5 has n data disks plus one dedicated parity-only disk; ZFS distributes all data and all parity across all disks
RAID-5 also spreads parity among all component disks. Each stripe, the parity disk is switched. This is done to achieve higher throughput on reads, as without it, one disk would always sit idle for read workloads.
ZFS updates metadata before data
Actually, ZFS updates metadata together with user data, but the trick is that the update is never performed in place. So what happens is that we write user data along with nearly all the metadata needed to access it. Then, once everything has finished writing (and has been sync'ed to stable storage), we update the root block pointers to point to the new metadata tree and again, sync those. In this respect ZFS is much more like an ACID-compliant database than just a conventional filesystem.
If anybody could sue Canonical for shipping ZFS in Ubuntu, it couldn't be Oracle, because the CDDL doesn't prohibit combining CDDL'd code with other licenses, provided the CDDL'd bits remain CDDL and that you distribute them to your users. It's the GPL that prohibits these combos - hence the "infectious license" moniker. So it'd have to be Linux copyright holders suing Canonical (oh the irony) for presumably combining the GPL'd Linux kernel with the CDDL'd ZFS code. Seeing as nothing like this has yet happened even with Canonical distributing the much more egregious Nvidia binary blob, I think the entire notion of this being a real legal hurdle is nothing but GPL-purist FUD.
The write hole in btrfs is AFIAK also present in zfs and listed as a risk of a power failure during write on a raid pool with COW filesystems.
The problem you describe makes no sense in ZFS. ZFS never overwrites in-place and a synchronous write is not acknowledged until all component devices (including parity) have sync'ed to stable storage. ZFS will never ever try to read a partially written stripe block (simply because it has no pointers to it yet). After a synchronous write (O_SYNC) returns, it is guaranteed to have all of its data available, regardless if it was overwriting a portion of a file in place, or appending new data to a file.
I think you're misunderstanding how raid-z actually works. raid-z is kinda like RAID-5, but not completely and it's this difference that allows ZFS to not have a write hole at all. All writes to a raid-z, regardless of size, are "full-stripe". The key in ZFS is that there is no fixed stripe size. I'd recommend Jeff Bonwick's original article on raid-z for a writeup of the principles and Matt Ahrens' article ZFS RAIDZ stripe width, or: How I Learned to Stop Worrying and Love RAIDZ for a nice diagram illustrating the layout.