Plaintext passwords over ssh have always bothered me. I always had a little program called 'sshlockout' which checks for failed password attempts via auth.log and lockout the IP, but that clearly won't work against something like this.
The only real solution is to disallow tunneled plaintext password logins entirely... simple enough, just set 'PasswordAuthentication no' in/etc/ssh/sshd_config (or wherever it lives). Problem solved.
Nobody should be using that sort of authentication any more anyway.
Having written an AHCI driver and worked endlessly on USB driver code there's no real point comparing the two. SATA is far, far, FAR more reliable. End of discussion. The USB chipset specs are horrid and the chipset implementations are even worse. Most chipsets barely pass through standard I/O operations properly and rarely deal with things like disk synchronization or even proper serial number reporting (for the USB bridge chips). USB has far higher cpu processing overheads and the DMA specs or so bad the driver often has to create bounce buffers. Command queueing overhead for a USB chipset is ridiculously huge compared to SATA chipsets.
USB is fine for a portable drive but only a complete fool uses USB if they need reliable mass storage.
E-SATA has its issues but they are nothing compared to the mess you get when you connect a drive up through USB. Frankly the only time one hits the 300 MByte/sec limit with today's SATA/E-SATA in a way that actually negatively impacts a production system is when one is talking to multiple targets over a port multiplier, on a single SATA port. The real need for 6GBit E-SATA is to better support port multipliers and not so much for SSDs.
While it is true that an SSD can hit the current 300 MByte/sec limit over SATA, there aren't really any realistic production loads against single drives (verses port multipliers) where an improvement in the bandwidth would actually improve the machine's ability to handle its workload.
HP installs so much crap our machines often stop booting entirely, take well over 5 minutes to reach a desktop, and perform poorly once they are up. And they install so much junk it's almost impossible to properly remove and clean it out. I've stopped buying *anything* HP because of that. It just isn't worth the frustration.
BSD distributions tend to be full vertical integrations. Linux distros tend to be horizontal integrations. There are, in fact, dozens of linux distros in various states of repair or disrepair. It's very easy for anyone to slap stuff together and call it a linux distro. It isn't so easy to slap together a BSD system and call IT a distro.
The various BSDs focus on different things though they do try to stay within shouting distance of each other. FreeBSD focuses on performance, OpenBSD on security, NetBSD on portability, and DragonFly focuses on a lofty filesystem clustering & SSI goal.
The HAMMER filesystem is a major stepping stone towards that goal. There is really no reason to use DragonFly if you do not also intend to use HAMMER, so it is probably lost on people who expect a pretty GUI and just want to play with DragonFly a little in a VirtualBox or VMWare or other VM with a tiny little virtual disk (VirtualBox doesn't even implement proper disk synchronization!). Real DragonFly consumers use it primarily for the filesystem, secondarily for the stability, and are willing to spend the extra time tuning the typical server applications that any UNIX-like OS can run in the mean time.
The differentiation here is that while something like ZFS focuses on redundancy, it does so using a monolithic filesystem model which is still vulnerable to software failures. HAMMER is designed to evolve into the core for DragonFly's clustering goals... HAMMER does not focus on individual filesystem redundancy but instead focuses on the components that will be needed to make the future multi-master clustering work efficiently. This also means that HAMMER must be rock solid and essentially bug free, which is a major task unto itself.
Thus HAMMER's mirroring components are designed to support live streaming replication (with near real-time backups being a convenient side effect) at the logical layer (HAMMER's B-Tree) as well as designed to become the bulk data transport component for the future clustering. This is very different from the discrete snapshots which numerous other filesystems support, and also very different from the traditional block-level mirroring slap-on model used to implement (for example) numerous Linux redundancy solutions.
In order to realize this multi-year goal we still need to provide what is basically a complete system solution in the mean time, otherwise there simply would not be enough users to keep the system well tested. And, unfortunately, keeping all the other components of a major distribution up-to-date take a huge amount of time just by themselves, but there's really no other way to do it. Politics make it virtually impossible to make the necessary changes to core OS structural mechanics required for the goal using someone else's distribution, so we have our own.
I've been around enough to know that no software lasts forever. Algorithms survive the test of time, but actual software typically does not. Small monolithic programs tend to survive the test of time too, simply because they are easier to port. A great deal of the linux infrastructure today is not small or monolithic and while it provides a very valuable service to its users it is also extremely vulnerable to obsolescence. If a linux distro dies all the work that went into it also tends to disappear. If a BSD distro dies the components are at least small and compact enough to survive in other forms. So in that respect the point of doing it should be obvious.
HAMMER is considered production-stable now. It was usable a year ago and what few bugs existed were found and fixed since then. Performance is much improved though we are still not happy with small file lookups, and fsyncs are still quite costly, but there isn't much we can do about it without some major on-media changes and those will probably not be made until after the cluster work ramps up. In anycase, HAMMER has been the default filesystem for a while. There is really no other choice for DragonFly (just as ZFS is the only real choice for FreeBSD) when it comes to dealing with today's huge drives. UFS (and UFS2) don't cut it.
Things have been slowly moving in this directly already, since game makers have not been using available cpu horsepower very effectively. A little z-buffer magic and there is no reason why the object space couldn't be separated into completely independent processing streams.
The only cursive I use, oh, since high school, is to write my signature. And I hardly even bother with that any more either. I just put down a squiggle.
It has to be automated or it won't work. If your backup scheme requires physical intervention to function normally, like swapping drives, it is destined to be a failure. It also has to provide live, directly addressable snapshots. Archival formats just don't work very well these days because it takes way, way too long to get to the data you might need to get to. Sure, a prudent company will always have some sort of archival or off-line storage for extreme emergencies, but the primary means of backup and restore today is live access. Only a really stupid person uses tape in the first two layers of backup.
One has to consider what one can do with the ridiculous amount of storage available on today's drives. Just a few weeks ago I slapped together a 10-Terrabyte 'test' filesystem with 2TB drives and a port multiplier enclosure. One E-SATA cable, 10TB. Its ridiculous how cheap this stuff has gotten over the last few years. But in terms of using all that storage, one of the goals of HAMMER (and to some extent ZFS) is to integrate live-snapshots into the filesystem itself. In the case of HAMMER's transactional storage (on DragonFlyBSD), you get fine-grained history, trivialized snapshot management, and bandwidth-controlled streaming mirroring for backup.
So the setup I have now is each box running HAMMER (on DragonFlyBSD) stores about 60-days worth of daily snapshots and one day's worth of fine-grained history on the production filesystem itself. Some of my boxes don't run HAMMER yet, and those I just cpdup/rdist over to the LAN backup box. Then there is a daily backup from the boxes on the LAN to a HAMMER-based LAN backup machine, and a weekly off-site backup from the LAN backup box to the off-site box. As I convert more of the machines over to HAMMER I can use the far more efficient streaming mirroring feature for HAMMER-HAMMER backups, and even make the daily backup a near real-time stream (and then cut to a daily snapshot each day), but particularly between the dedicated HAMMER filesystem on the LAN backup box and on the off-site box.
The big advantage of having the ability to maintain hundreds of snapshots is of course that you do not need to use the horrible cruft-multiplying 'hardlink' trick to maintain each snapshot. My LAN backup box can maintain about 120 daily snapshots of all my machines and my off-site box can store over a year's worth of weekly snapshots. My base backup set is well over 200GB now. Each day adds a few gigs, so a single terrabyte drive can hold a considerable number of snapshots.
And in terms of taking drives off-line for storing on a shelf, which is a reasonable thing to do as long as NOT doing so doesn't interfere with normal backup operations... it is far easier to do that with fewer larger drives then to do that with drive arrays. If you are taking physical possession you really only want to have to deal with one drive. In the case of HAMMER I just have a second mirroring stream going to a dedicate easily-pullable drive (via an E-Sata hot swap enclosure) which does not interfere with the nominal automated chain backups.
ZFS's raid-z is quite nice, but not really suitable for a backup system unless your backup needs exceeds a few terrabytes. It's a waste of power and money to construct redundancy for a single filesystem when 2TB drives can be bought and one can construct redundancy by creating multiple, independant backups. Ultimately it does get large enough to warrant at least hard-mirroring so things continue to click along if a drive failure occurs, but for most people its just wasteful to do that. If one already has a chain of backups (and thus redundancy in the form of completely independant copies), the occasional failure of a portion of the chain isn't that big a deal.
Where ZFS really works well is on the production system in a non-clustered environment. HAMMER doesn't really do in-filesystem redundancy (i.e. we'd have to depend on a hardware or software RAID layer), but HAMMER's goal is ultimately (as in the ultimate goal of the project) to integrate into a cluster of independantly-run copies of the same filesystem and in that sort of topology one does not actually want each individual copy to itself be redundant... it would just be wasted storage.
SSDs are not likely to replace traditional hard drives any time soon, if ever. The cost differential is simply too high. While it is true that SSDs can effectively replace HDs on systems which do not require large amounts of storage (say, 64G-256G), the fact of the matter is that a 256G SSD is still three times as expensive as a 2TB hard drive. That is a 24:1 cost factor.
At the same time SSDs are becoming capable of replacing systems which do not have large storage requirements, HDs are becoming far more capable in systems which DO have large storage requirements, and driven by high resolution digital camera and video media consumer trends are clearly heading towards the larger storage requirement end of the spectrum.
The way I see it, the advent of SSD storage gives us the ability to extend the cache layering abstraction we already use into a smooth continuum between the cpu's L1 cache (L2, L3, dram simms, etc...) and traditional HD-based disk cache. SDD doesn't quite close the gap but it actually fills a major portion of it.
The article makes the mistake of assuming fairly small SSDs, but is otherwise spot-on. It isn't possible to use tiny SSDs in the 8G range as a paging medium for caching memory, it simply isn't enough storage for wear levels to be acceptable. On the other-hand, a 64G-256G SSD provides a better basis both in wear leveling and in traditional cache metrics. This is particularly true as hard drives exceed the 2TB/unit mark.
There is a general fallacy here where some people seem to believe that SSDs will replace hard drives. That is not going to happen any time soon or possibly even ever, not unless flash densities can be increased by two orders of magnitude. The cost per byte of storage is immense between the two. What *IS* happening is that SSDs are now capable of replacing HDs in particular circumstances where the absolute quantity of storage is not the primary need. At the same time traditional HDs themselves have replaced a large portion of the spectrum that used to be held by archival media, and the need for terrabyte-sized storage systems has increased drastically as high resolution digital cameras and video become more important to the general consumer.
I think most people still have the 'paging is bad' mindset, because traditional paging is a fairly inefficient operation on a traditional hard drive. That isn't the case when it comes to SSDs as the technology matures. Paging, in fact, could become the tour-De-force that allows systems to more fully utilize all of their resources. SSDs have not quite gotten to this point yet but it is obvious that they will quickly get there, probably in as little as two years.
If the author uses a lot of power then it could very well all be top-tier usage. That's pretty much how my solar installation works. I use a lot of power, and my solar takes it right off the top-tier. Someone using less power would not have enough KwH-use in their top tier and their solar would dip into a lower tier.
Even saying that, doing a Solar installation is a lot more about being more green then it is about actually saving money. The greenhouse cost of building a solar panel has about a 1-2 year payback in terms of energy produced, which is a different measure then the payback on dollars spent. With a 25 year life-span on the panels a Solar installation ultimately has just 1/10 the impact verses not having it.
-Matt
Re:Be careful about your hardware and software
on
Best eSATA JBOD?
·
· Score: 1
If you use an AHCI controller it has to have the FBSS (Fis-Based switching) capability, which is basically AHCI1.3 as long as the capability bit is also set. The AHCI driver must also support the feature. Very few AHCI controllers have this capability, it is very new. The AHCI driver must also support AHCI's NCQ (multiple tagged commands). Most AHCI controllers have NCQ support now but if the driver doesn't you'll be stuck with horrible performance. Your chipset and driver needs to support both NCQ and FBSS to get decent performance through a port-multiplier-based enclosure.
Other non-AHCI controllers can also do Fis-Based switching, most notably something like the ultra cheap Silicon Image 3132. However, you have to be extremely careful with these chips because they have some significant hardware bugs and if the driver software doesn't work around the bugs you will get a lot of data corruption.
Unfortunately, even with the correct combination of software and hardware and FBSS, enclosures which use SATA-based Port Multipliers are still very sensitive to error conditions. For all intents and purposes if a device has a problem, the entire port multiplier enclosure has to be idled to clear the condition. So while this stuff can be used for RAID-like setups don't count on performance being maintained if one the disks starts to go bad.
There are a ton of cheap PM (Port Multiplier-based) enclosures on the market which take SATA drives, a lot of them use Silicon Image port-multiplier chips (I forget the exact chip number). The chips work but are a bit quirky. Still, drivers can work around the issues and still get reliable Hot-Swap events. The main reason for using something like that is to be able to have a simple backplane in the PM enclosure so the drives can be hot-swap. Most of these enclosure chipsets do seem to support Fis-based switching. Everything in the chain has to support it or it can't be used.
Port-multiplier-based SATA hot-swap enclosures are the cheapest available. Prices will probably continue to drop since the hardware needed is minimal. It's basically two chips, a backplane, a power supply, and the hot-swap elements.
In terms of operating systems and drivers. Well, Linux seems to have fairly decent drivers. I just finished doing full-on drivers for DragonFly for AHCI and the Sili 3132. The Sili driver can do FBSS+NCQ. The AHCI driver can only do NCQ atm. Plus Hot-swap, of course. I think Solaris has a decent AHCI driver. Other OS's have drivers with varying levels of support (w/ regard to NCQ, FBSS, Port-Multiplier, Hot-swap, and PM-based hot-swap support), and varying levels of robustness.
Another way to go is with the more expensive SAS chipsets. These can generally handle SATA drives too and theoretically have a more robust hardware programming interface.
I have noticed that motherboard prices for higher-end AMD Phenom systems seem to be a lot lower then MB prices for Intel I7 systems. AMD's high integration approach seems to be paying off there. The only real issue seems to be AMDs lack of support for larger 16G memory configurations in its desktop line.
The whole-system price for a Phenom X4 system (using e.g. A Shuttle SN78SH7 as a base) is less then $600. Every year it seems I can buy a cheap off-the-shelf barebones system and completely replace several of the previous year's servers, if not for the HD performance requirements. The biggest constraint for ALL of my machines, these days, is HD performance.
On the storage and performance front I think the addition of external ESATA connectors to base motherboards may actually be the more important change. Manufacturers made the same mistake with direct, native NAS that they made with SCSI... they blew it by keeping prices ridiculously high. It is the same thing that allowed SATA to take over much of the consumer and mid-sized business markets from SCSI over the last few years. Now NAS has been relegated to having to compete directly with high-level protocols like NFS and is getting squeezed into a smaller niche. Firewire has become standardized too but could never break into the HD market as a native connection standard. The end result is that ESATA is likely to consolidate and become *THE* connect standard of choice for external storage subsystems.
Wavelength doesn't really count as a dimension for stroage, nor can one store an infinite amount of information by using an infinite number of frequencies. However, polarization could be considered a dimension for the purposes of storage.
The problem with anything in the frequency domain is that you cannot encode a single frequency without creating a spread which crosses multiple frequencies. This limits how short a pulse one can encode at the desired frequency and how closely one can pack discrete frequencies together to encode different data. Coupled with the noise floor the combination limits the amount of data which can be stored in the frequency domain.
for example, if you were to look at the fourier transform of a sine wave you would see a single frequency. However, if you were to look at the fourier transform of the sine wave and INCLUDE the lack of a sine wave before and after the sine wave pulse being encoded, you would see a log of bleedover into other frequencies due to the ramp-up and ramp-down times. Any change, such as going from flatline to a sine-wave, will create a lot of harmonics. Harmonics can be reduced (but not eliminated) by using an envelope to ramp-up or ramp-down the operation, but an envelope of course requires the pulse duration to be longer. So the amount of data which can be stored is limited no matter what you do.
It works a bit differently when one is working in a quantum mechanical domain... in that case it is possible to store discrete information at discrete frequencies, but you only have particular frequencies to work with, typically related to the energy level of the electrons being knocked around.
I can produce one-offs just fine even with a cheap crimper, but it takes some effort (and sometimes a few wasted heads) to get it right. There really isn't much of a choice if you have to run a long cable anyway.
My experience with patch-sized cables is you buy them, not make them. We once had an installer come in to wire up a panel who had built all his patch cables by hand. After the third one failed I ripped every single patch cable out and replaced it with bulk-bought cables. And in my own experience I've never been able to get more then one in three correctly made the first time and one in ten will look fine but not work properly when installed.
It wasn't so bad in the 100BaseT days where only two-pair out of the cable are actually used. Anyone else remember doubling up 100BaseT links on the same cable to save space?
GigE is a different story. Every single pair has to have a solid connection and you need the inter-cable spacing provided by the insulators or you wind up with all sorts of odd issues.
It turns out that the cost of a translation layer has become irrelevant as chips have gotten faster. It's not even considered a pipeline stage any more, not really. That is, it is no longer a bottleneck to have to have a layer of essentially combinational logic to convert a CISC instruction set into a mostly RISC / VLIW one internally. This savings grace is also why the fairly badly bloated intel instruction set no longer has any real impact on the performance they can squeeze out of the chips.
Yes, corecode converted DragonFlyBSD from CVS to git using fromcvs. It did a very good job on the head and most of the branches. I think there were more substantial issues converting the vendor branches but all in all it did a good job. Of course, once you get them into git maintaining vendor branches becomes utterly trivial.
The DragonFly project switched to git late last year. I consider the conversion a big success and, frankly, just being able to have the mirrors sync on a 5 minute interval made it worth it even if one disregards all the other advantages. With CVS our mirrors couldn't sync more then a few times a day due to machine and network load.
We were also getting really, really tired of cvsup.
git makes developer-maintained branches for large side projects ultra easy to do. The 'git daemon' feature allowed us to trivially export all developer side projects from our developer shell box. The branching and merging features in git are very powerful. gitk, gitweb, and other tools in the git space are very nice. It is open-source at its best.
When considering what repo to move to we also looked at svn and mercurial. svn was discarded, it was simply inadequate... kinda like CVS with a few of the issues fixed but no real advancement in the technology. Mercurial was still an option but its lack of proper branching support doomed it. GIT won in the end and we haven't looked back since.
Disk space is not an issue at all. One of the common complaints about git is the.git sub-directory containing a copy of the repo. It did take a little getting used to but frankly after a month or two we stopped worrying about it. Syncing is so fast and hard drives are so large these days one just doesn't notice the extra copies or feel a need to optimize or reduce. Though of course I still use NFS to distribute active sources to test machines so I can edit the sources on a stable machine.
Syncing mechanics are very flexible. Being able to both push and pull combined with ultra-fine branch management is a major win-win.
Actually, that isn't quite true either. If the ISP end of the connection is taking a T1 then one entire channel is reserved for out-of-band signaling, leaving (I think) 23 64 Kbit channels available for modem connections. I remember there were two options available and to make 56Kbit modems work well we had to use the out-of-band signaling option, which reduced the number of phone lines we had on each T1 by one.
Direct T1s quickly became the standard for ISPs starting around 1994 ish, until T3's became cheap in '95 and '96. By 1998 most medium and large ISPs were splitting channels out of fiber directly, or had farmed their physical dialup to third parties which then backhauled them back to the ISP.
Phone companies also played their own games involving far more then an 8Kbit loss, but by the late 90's they could only use those tricks in places where they had insufficient physical copper to meet demand and they couldn't hide the fact that modems simply didn't work well with the line doubler technology they were forced to use in those places.
I think one can say confidently that SSDs do not have the same near-term catastrophic failure issues that HDs have. A SSD will be about as reliable as, say, the motherboard in a computer. Certain parts within the SSD, such as electrolytic capacitors, have limited life spans, but no more limited then the electronics inside a hard drive. Many people in the server space talk about putting their boot partition on RAID to ensure that the machine is still able to boot with a failed hard drive. You don't need to do that if you use a SSD for your boot disk. Because the SSD is no less reliable then the motherboard it makes little sense to have additional redundancy in that context. Once you are booting from reliable media you have a lot more redundancy options for the rest of the media accessed by the machine. For example, there is no need to RAID the local disks within the local hardware, the redundancy can be networked instead.
However, the ability to recover from a flash that has been sitting on a shelf too long is a real issue compared to a HD. Both suffer thermal degradation over time but even if a HD's moving parts become unusable it is still possible to do a surface scan and recover the data after a long period of time has passed, even if it costs a few thousand dollars to do it. Once a flash cell leaks into the ether the data is virtually unrecoverable. There is nothing to scan. Theoretically one can shave the top off the chip and use a tunneling microscope to scan it (the Taiwanese did this to read out 'protected' EEROM from integrated cpu chips years ago), but the expense would be enormous, in the hundreds of thousands of dollars per unit or more, with no re-takes if it fails (the chip would be effectively destroyed). Flash-based media is NOT archival storage.
This is even more true for flash cells nearing the ends of their lives, after they've been rewritten a lot. The first write in a freshly minted flash memory will survive on the shelf far longer then the last successful write before a cell fails. The achilles heal of flash is the wear issue, and this limits its usefulness in server environments unless you explicitly replace the unit once a year as part of your regular maintenance. The risk is you put an often-used SSD on the shelf and a few years later the entire data set is corrupted beyond recovery.
On the flip side, your average consumer does not actually generate a lot of data. One terrabyte worth of writes on a 256G medium is only about 4 rewrites assuming perfect wear leveling, well within the 100,000 rewrites available. The AMOUNT of data is irrelevant. It's the amount of REWRITING that matters. We all know that the vast majority of the data sitting on those terrabyte drives is static. The problem is much reduced as the media capacity of the SSD increases. In a sense, the SSD problem is the same as the backup problem. Since you have to backup your machines anyway, your average rewrite bandwidth is limited by virtue of your backup bandwidth being limited. This would be true for most large data stores as well.
So it comes down to the price we pay per gigabyte. SSDs are clearly still way too expensive, particularly with HD capacities likely increasing past 10 Terrabytes in the next 5 years. SSDs simply cannot grow at the same rate as HDs, they are severely limited by fabrication issues that HD manufacturers do not have. The HD manufacturer can put an immense expense into the construction of the relatively tiny disk head if need-be without increasing the cost of the overall unit very much. The same cannot be said for the fabrication of flash memory chips.
SSDs have their foot in the door, though. The price really only needs to come down another 30% or so for the use cases to explode. This is still nowhere near the equivalent cost per gigabyte of a HD, but it doesn't have to be to gain mass acceptance. At some point in the next 10 years a new technology will pop up, perhaps it will be IBM's magnetic memory! Perhaps something else, that will solve flash memory's wear issues. When that occurs the mass acceptance will turn into an explosion of use cases.
Right now the biggest problem ISPs have with bittorrent is not the bandwidth it uses, but the massive packet load it puts on their border routers, DSLAMs, etc. This is 99% due to allowing hundreds of simultaneous incoming connections. bittorrent clients have never been able to throttle incoming bandwidth aggregated across hundreds of connections very well, and the result is thousands of packets worth of backlog on the ISP's border routers, DSLAMs, etc, which blows them up.
Changing to UDP does not solve this problem, it just makes things even worse. The bittorrent people need to get their act together. The ISPs are just going to respond by changing their bandwidth filtering to be whole-IP-based instead of connection-based, and the result will be that people trying to use bittorrent will wind up with crappy, unreliable links for EVERYTHING they are trying to do over the internet.
I don't know why people using bittorrent should expect the ISPs to 'play nice' when they clearly don't give a damn about the mess bittorrent makes of the ISPs own infrastructure.
If you hear a sound like morse-code in the speakers it's just the cellular phone transmitting something in close proximity to your system.
The problem isn't the cellular phone, it is simply that your computer's speaker cables and electronics tend to be unshielded. Sometimes the power cable itself is to blame, sometimes its the traces in the amplifier, but mostly it's the speaker cabling.
In any case, it usually doesn't take more then a $0.10 ferrite bead around the cables in question to remove the problem. That's why you often see ferrite beads built into monitor cables.
I have to say, the ZFS folks have convinced me. There are simply too many places where bit rot can creep in these days even when the drive itself is perfect. The fact that the drive is not perfect just puts a big exclamation point on the issue. Add other problems into the fray, such as phantom writes (which have also been demonstrated to occur), and it gets very scary very quickly.
I don't agree with ZFS's race-to-root block updating scheme for filesystem integrity but I do agree with the necessity of not completely trusting the block storage subsystem and of building checks into the filesystem data structures themselves.
Even more specifically, if one is managing very large amounts of data one needs a way to validate that the filesystem contains what it is supposed to contain. It simply isn't possible to do that with storage-system logic. The filesystem itself must contain sufficient information to make validation possible. The filesystem itself must contain CRCs and hierarchical validation mechanisms to have a proper end-to-end check. I plan on making some adjustments to HAMMER to fix some holes in validation checking that I missed in the first round.
The DragonFly project is planning on moving out of CVS and has been looking at various repositories. We aren't actually interested in Subversion per-say, not any more, but some of our developers have used GIT and a few are advocating for mercurial as well. We need to come to a decision by mid-november.
I haven't used Mercurial yet myself. I have used GIT. It took about a week to get used to it but once I understood the contextual labels things became a lot more obvious. We will maintain our central repository either by having it pull from the individual developer's repositories or by having the developers push into it. I'm still not quite sure what the best methodology is. It has to be automated no matter what.
If someone is using GIT in a similar manner I would like to hear your story.
I would also like to solicit opinions from people on GIT vs Mercurial.
You can still buy HUBs for 10BaseT. Clearly nobody trying to use ethernet for a SAN is going to be using HUBbed 10BaseT.
Nobody in their right mind uses 100BaseT hubs unless they just want to sniff the port (since most dumb switches do not have monitoring features). I've never even seen 100BaseT hubs, do they even exist? Well, there's no reason to buy one anyway even if they do.
There has not been a cost basis for using a HUB for at least a decade. There's no point even arguing about it any more.
Slashdot Mirror
Plaintext passwords over ssh have always bothered me. I always had a little program called 'sshlockout' which checks for failed password attempts via auth.log and lockout the IP, but that clearly won't work against something like this.
The only real solution is to disallow tunneled plaintext password logins entirely... simple enough, just set 'PasswordAuthentication no' in /etc/ssh/sshd_config (or wherever it lives). Problem solved.
Nobody should be using that sort of authentication any more anyway.
-Matt
Having written an AHCI driver and worked endlessly on USB driver code there's no real point comparing the two. SATA is far, far, FAR more reliable. End of discussion. The USB chipset specs are horrid and the chipset implementations are even worse. Most chipsets barely pass through standard I/O operations properly and rarely deal with things like disk synchronization or even proper serial number reporting (for the USB bridge chips). USB has far higher cpu processing overheads and the DMA specs or so bad the driver often has to create bounce buffers. Command queueing overhead for a USB chipset is ridiculously huge compared to SATA chipsets.
USB is fine for a portable drive but only a complete fool uses USB if they need reliable mass storage.
E-SATA has its issues but they are nothing compared to the mess you get when you connect a drive up through USB. Frankly the only time one hits the 300 MByte/sec limit with today's SATA/E-SATA in a way that actually negatively impacts a production system is when one is talking to multiple targets over a port multiplier, on a single SATA port. The real need for 6GBit E-SATA is to better support port multipliers and not so much for SSDs.
While it is true that an SSD can hit the current 300 MByte/sec limit over SATA, there aren't really any realistic production loads against single drives (verses port multipliers) where an improvement in the bandwidth would actually improve the machine's ability to handle its workload.
-Matt
HP installs so much crap our machines often stop booting entirely, take well over 5 minutes to reach a desktop, and perform poorly once they are up. And they install so much junk it's almost impossible to properly remove and clean it out. I've stopped buying *anything* HP because of that. It just isn't worth the frustration.
-Matt
BSD distributions tend to be full vertical integrations. Linux distros tend to be horizontal integrations. There are, in fact, dozens of linux distros in various states of repair or disrepair. It's very easy for anyone to slap stuff together and call it a linux distro. It isn't so easy to slap together a BSD system and call IT a distro.
The various BSDs focus on different things though they do try to stay within shouting distance of each other. FreeBSD focuses on performance, OpenBSD on security, NetBSD on portability, and DragonFly focuses on a lofty filesystem clustering & SSI goal.
The HAMMER filesystem is a major stepping stone towards that goal. There is really no reason to use DragonFly if you do not also intend to use HAMMER, so it is probably lost on people who expect a pretty GUI and just want to play with DragonFly a little in a VirtualBox or VMWare or other VM with a tiny little virtual disk (VirtualBox doesn't even implement proper disk synchronization!). Real DragonFly consumers use it primarily for the filesystem, secondarily for the stability, and are willing to spend the extra time tuning the typical server applications that any UNIX-like OS can run in the mean time.
The differentiation here is that while something like ZFS focuses on redundancy, it does so using a monolithic filesystem model which is still vulnerable to software failures. HAMMER is designed to evolve into the core for DragonFly's clustering goals... HAMMER does not focus on individual filesystem redundancy but instead focuses on the components that will be needed to make the future multi-master clustering work efficiently. This also means that HAMMER must be rock solid and essentially bug free, which is a major task unto itself.
Thus HAMMER's mirroring components are designed to support live streaming replication (with near real-time backups being a convenient side effect) at the logical layer (HAMMER's B-Tree) as well as designed to become the bulk data transport component for the future clustering. This is very different from the discrete snapshots which numerous other filesystems support, and also very different from the traditional block-level mirroring slap-on model used to implement (for example) numerous Linux redundancy solutions.
In order to realize this multi-year goal we still need to provide what is basically a complete system solution in the mean time, otherwise there simply would not be enough users to keep the system well tested. And, unfortunately, keeping all the other components of a major distribution up-to-date take a huge amount of time just by themselves, but there's really no other way to do it. Politics make it virtually impossible to make the necessary changes to core OS structural mechanics required for the goal using someone else's distribution, so we have our own.
I've been around enough to know that no software lasts forever. Algorithms survive the test of time, but actual software typically does not. Small monolithic programs tend to survive the test of time too, simply because they are easier to port. A great deal of the linux infrastructure today is not small or monolithic and while it provides a very valuable service to its users it is also extremely vulnerable to obsolescence. If a linux distro dies all the work that went into it also tends to disappear. If a BSD distro dies the components are at least small and compact enough to survive in other forms. So in that respect the point of doing it should be obvious.
-Matt
HAMMER is considered production-stable now. It was usable a year ago and what few bugs existed were found and fixed since then. Performance is much improved though we are still not happy with small file lookups, and fsyncs are still quite costly, but there isn't much we can do about it without some major on-media changes and those will probably not be made until after the cluster work ramps up. In anycase, HAMMER has been the default filesystem for a while. There is really no other choice for DragonFly (just as ZFS is the only real choice for FreeBSD) when it comes to dealing with today's huge drives. UFS (and UFS2) don't cut it.
-Matt
Things have been slowly moving in this directly already, since game makers have not been using available cpu horsepower very effectively. A little z-buffer magic and there is no reason why the object space couldn't be separated into completely independent processing streams.
-Matt
The only cursive I use, oh, since high school, is to write my signature. And I hardly even bother with that any more either. I just put down a squiggle.
-Matt
It has to be automated or it won't work. If your backup scheme requires physical intervention to function normally, like swapping drives, it is destined to be a failure. It also has to provide live, directly addressable snapshots. Archival formats just don't work very well these days because it takes way, way too long to get to the data you might need to get to. Sure, a prudent company will always have some sort of archival or off-line storage for extreme emergencies, but the primary means of backup and restore today is live access. Only a really stupid person uses tape in the first two layers of backup.
One has to consider what one can do with the ridiculous amount of storage available on today's drives. Just a few weeks ago I slapped together a 10-Terrabyte 'test' filesystem with 2TB drives and a port multiplier enclosure. One E-SATA cable, 10TB. Its ridiculous how cheap this stuff has gotten over the last few years. But in terms of using all that storage, one of the goals of HAMMER (and to some extent ZFS) is to integrate live-snapshots into the filesystem itself. In the case of HAMMER's transactional storage (on DragonFlyBSD), you get fine-grained history, trivialized snapshot management, and bandwidth-controlled streaming mirroring for backup.
So the setup I have now is each box running HAMMER (on DragonFlyBSD) stores about 60-days worth of daily snapshots and one day's worth of fine-grained history on the production filesystem itself. Some of my boxes don't run HAMMER yet, and those I just cpdup/rdist over to the LAN backup box. Then there is a daily backup from the boxes on the LAN to a HAMMER-based LAN backup machine, and a weekly off-site backup from the LAN backup box to the off-site box. As I convert more of the machines over to HAMMER I can use the far more efficient streaming mirroring feature for HAMMER-HAMMER backups, and even make the daily backup a near real-time stream (and then cut to a daily snapshot each day), but particularly between the dedicated HAMMER filesystem on the LAN backup box and on the off-site box.
The big advantage of having the ability to maintain hundreds of snapshots is of course that you do not need to use the horrible cruft-multiplying 'hardlink' trick to maintain each snapshot. My LAN backup box can maintain about 120 daily snapshots of all my machines and my off-site box can store over a year's worth of weekly snapshots. My base backup set is well over 200GB now. Each day adds a few gigs, so a single terrabyte drive can hold a considerable number of snapshots.
And in terms of taking drives off-line for storing on a shelf, which is a reasonable thing to do as long as NOT doing so doesn't interfere with normal backup operations... it is far easier to do that with fewer larger drives then to do that with drive arrays. If you are taking physical possession you really only want to have to deal with one drive. In the case of HAMMER I just have a second mirroring stream going to a dedicate easily-pullable drive (via an E-Sata hot swap enclosure) which does not interfere with the nominal automated chain backups.
ZFS's raid-z is quite nice, but not really suitable for a backup system unless your backup needs exceeds a few terrabytes. It's a waste of power and money to construct redundancy for a single filesystem when 2TB drives can be bought and one can construct redundancy by creating multiple, independant backups. Ultimately it does get large enough to warrant at least hard-mirroring so things continue to click along if a drive failure occurs, but for most people its just wasteful to do that. If one already has a chain of backups (and thus redundancy in the form of completely independant copies), the occasional failure of a portion of the chain isn't that big a deal.
Where ZFS really works well is on the production system in a non-clustered environment. HAMMER doesn't really do in-filesystem redundancy (i.e. we'd have to depend on a hardware or software RAID layer), but HAMMER's goal is ultimately (as in the ultimate goal of the project) to integrate into a cluster of independantly-run copies of the same filesystem and in that sort of topology one does not actually want each individual copy to itself be redundant... it would just be wasted storage.
-Matt
SSDs are not likely to replace traditional hard drives any time soon, if ever. The cost differential is simply too high. While it is true that SSDs can effectively replace HDs on systems which do not require large amounts of storage (say, 64G-256G), the fact of the matter is that a 256G SSD is still three times as expensive as a 2TB hard drive. That is a 24:1 cost factor.
At the same time SSDs are becoming capable of replacing systems which do not have large storage requirements, HDs are becoming far more capable in systems which DO have large storage requirements, and driven by high resolution digital camera and video media consumer trends are clearly heading towards the larger storage requirement end of the spectrum.
-Matt
The way I see it, the advent of SSD storage gives us the ability to extend the cache layering abstraction we already use into a smooth continuum between the cpu's L1 cache (L2, L3, dram simms, etc...) and traditional HD-based disk cache. SDD doesn't quite close the gap but it actually fills a major portion of it.
The article makes the mistake of assuming fairly small SSDs, but is otherwise spot-on. It isn't possible to use tiny SSDs in the 8G range as a paging medium for caching memory, it simply isn't enough storage for wear levels to be acceptable. On the other-hand, a 64G-256G SSD provides a better basis both in wear leveling and in traditional cache metrics. This is particularly true as hard drives exceed the 2TB/unit mark.
There is a general fallacy here where some people seem to believe that SSDs will replace hard drives. That is not going to happen any time soon or possibly even ever, not unless flash densities can be increased by two orders of magnitude. The cost per byte of storage is immense between the two. What *IS* happening is that SSDs are now capable of replacing HDs in particular circumstances where the absolute quantity of storage is not the primary need. At the same time traditional HDs themselves have replaced a large portion of the spectrum that used to be held by archival media, and the need for terrabyte-sized storage systems has increased drastically as high resolution digital cameras and video become more important to the general consumer.
I think most people still have the 'paging is bad' mindset, because traditional paging is a fairly inefficient operation on a traditional hard drive. That isn't the case when it comes to SSDs as the technology matures. Paging, in fact, could become the tour-De-force that allows systems to more fully utilize all of their resources. SSDs have not quite gotten to this point yet but it is obvious that they will quickly get there, probably in as little as two years.
-Matt
If the author uses a lot of power then it could very well all be top-tier usage. That's pretty much how my solar installation works. I use a lot of power, and my solar takes it right off the top-tier. Someone using less power would not have enough KwH-use in their top tier and their solar would dip into a lower tier.
Even saying that, doing a Solar installation is a lot more about being more green then it is about actually saving money. The greenhouse cost of building a solar panel has about a 1-2 year payback in terms of energy produced, which is a different measure then the payback on dollars spent. With a 25 year life-span on the panels a Solar installation ultimately has just 1/10 the impact verses not having it.
-Matt
If you use an AHCI controller it has to have the FBSS (Fis-Based switching) capability, which is basically AHCI1.3 as long as the capability bit is also set. The AHCI driver must also support the feature. Very few AHCI controllers have this capability, it is very new. The AHCI driver must also support AHCI's NCQ (multiple tagged commands). Most AHCI controllers have NCQ support now but if the driver doesn't you'll be stuck with horrible performance. Your chipset and driver needs to support both NCQ and FBSS to get decent performance through a port-multiplier-based enclosure.
Other non-AHCI controllers can also do Fis-Based switching, most notably something like the ultra cheap Silicon Image 3132. However, you have to be extremely careful with these chips because they have some significant hardware bugs and if the driver software doesn't work around the bugs you will get a lot of data corruption.
Unfortunately, even with the correct combination of software and hardware and FBSS, enclosures which use SATA-based Port Multipliers are still very sensitive to error conditions. For all intents and purposes if a device has a problem, the entire port multiplier enclosure has to be idled to clear the condition. So while this stuff can be used for RAID-like setups don't count on performance being maintained if one the disks starts to go bad.
There are a ton of cheap PM (Port Multiplier-based) enclosures on the market which take SATA drives, a lot of them use Silicon Image port-multiplier chips (I forget the exact chip number). The chips work but are a bit quirky. Still, drivers can work around the issues and still get reliable Hot-Swap events. The main reason for using something like that is to be able to have a simple backplane in the PM enclosure so the drives can be hot-swap. Most of these enclosure chipsets do seem to support Fis-based switching. Everything in the chain has to support it or it can't be used.
Port-multiplier-based SATA hot-swap enclosures are the cheapest available. Prices will probably continue to drop since the hardware needed is minimal. It's basically two chips, a backplane, a power supply, and the hot-swap elements.
In terms of operating systems and drivers. Well, Linux seems to have fairly decent drivers. I just finished doing full-on drivers for DragonFly for AHCI and the Sili 3132. The Sili driver can do FBSS+NCQ. The AHCI driver can only do NCQ atm. Plus Hot-swap, of course. I think Solaris has a decent AHCI driver. Other OS's have drivers with varying levels of support (w/ regard to NCQ, FBSS, Port-Multiplier, Hot-swap, and PM-based hot-swap support), and varying levels of robustness.
Another way to go is with the more expensive SAS chipsets. These can generally handle SATA drives too and theoretically have a more robust hardware programming interface.
-Matt
I have noticed that motherboard prices for higher-end AMD Phenom systems seem to be a lot lower then MB prices for Intel I7 systems. AMD's high integration approach seems to be paying off there. The only real issue seems to be AMDs lack of support for larger 16G memory configurations in its desktop line.
The whole-system price for a Phenom X4 system (using e.g. A Shuttle SN78SH7 as a base) is less then $600. Every year it seems I can buy a cheap off-the-shelf barebones system and completely replace several of the previous year's servers, if not for the HD performance requirements. The biggest constraint for ALL of my machines, these days, is HD performance.
On the storage and performance front I think the addition of external ESATA connectors to base motherboards may actually be the more important change. Manufacturers made the same mistake with direct, native NAS that they made with SCSI... they blew it by keeping prices ridiculously high. It is the same thing that allowed SATA to take over much of the consumer and mid-sized business markets from SCSI over the last few years. Now NAS has been relegated to having to compete directly with high-level protocols like NFS and is getting squeezed into a smaller niche. Firewire has become standardized too but could never break into the HD market as a native connection standard. The end result is that ESATA is likely to consolidate and become *THE* connect standard of choice for external storage subsystems.
-Matt
Wavelength doesn't really count as a dimension for stroage, nor can one store an infinite amount of information by using an infinite number of frequencies. However, polarization could be considered a dimension for the purposes of storage.
The problem with anything in the frequency domain is that you cannot encode a single frequency without creating a spread which crosses multiple frequencies. This limits how short a pulse one can encode at the desired frequency and how closely one can pack discrete frequencies together to encode different data. Coupled with the noise floor the combination limits the amount of data which can be stored in the frequency domain.
for example, if you were to look at the fourier transform of a sine wave you would see a single frequency. However, if you were to look at the fourier transform of the sine wave and INCLUDE the lack of a sine wave before and after the sine wave pulse being encoded, you would see a log of bleedover into other frequencies due to the ramp-up and ramp-down times. Any change, such as going from flatline to a sine-wave, will create a lot of harmonics. Harmonics can be reduced (but not eliminated) by using an envelope to ramp-up or ramp-down the operation, but an envelope of course requires the pulse duration to be longer. So the amount of data which can be stored is limited no matter what you do.
It works a bit differently when one is working in a quantum mechanical domain... in that case it is possible to store discrete information at discrete frequencies, but you only have particular frequencies to work with, typically related to the energy level of the electrons being knocked around.
-Matt
I can produce one-offs just fine even with a cheap crimper, but it takes some effort (and sometimes a few wasted heads) to get it right. There really isn't much of a choice if you have to run a long cable anyway.
My experience with patch-sized cables is you buy them, not make them. We once had an installer come in to wire up a panel who had built all his patch cables by hand. After the third one failed I ripped every single patch cable out and replaced it with bulk-bought cables. And in my own experience I've never been able to get more then one in three correctly made the first time and one in ten will look fine but not work properly when installed.
It wasn't so bad in the 100BaseT days where only two-pair out of the cable are actually used. Anyone else remember doubling up 100BaseT links on the same cable to save space?
GigE is a different story. Every single pair has to have a solid connection and you need the inter-cable spacing provided by the insulators or you wind up with all sorts of odd issues.
-Matt
Get into a new business: Sell collocated virtualized machines and network bandwidth.
-Matt
It turns out that the cost of a translation layer has become irrelevant as chips have gotten faster. It's not even considered a pipeline stage any more, not really. That is, it is no longer a bottleneck to have to have a layer of essentially combinational logic to convert a CISC instruction set into a mostly RISC / VLIW one internally. This savings grace is also why the fairly badly bloated intel instruction set no longer has any real impact on the performance they can squeeze out of the chips.
-Matt
Yes, corecode converted DragonFlyBSD from CVS to git using fromcvs. It did a very good job on the head and most of the branches. I think there were more substantial issues converting the vendor branches but all in all it did a good job. Of course, once you get them into git maintaining vendor branches becomes utterly trivial.
The DragonFly project switched to git late last year. I consider the conversion a big success and, frankly, just being able to have the mirrors sync on a 5 minute interval made it worth it even if one disregards all the other advantages. With CVS our mirrors couldn't sync more then a few times a day due to machine and network load.
We were also getting really, really tired of cvsup.
git makes developer-maintained branches for large side projects ultra easy to do. The 'git daemon' feature allowed us to trivially export all developer side projects from our developer shell box. The branching and merging features in git are very powerful. gitk, gitweb, and other tools in the git space are very nice. It is open-source at its best.
When considering what repo to move to we also looked at svn and mercurial. svn was discarded, it was simply inadequate... kinda like CVS with a few of the issues fixed but no real advancement in the technology. Mercurial was still an option but its lack of proper branching support doomed it. GIT won in the end and we haven't looked back since.
Disk space is not an issue at all. One of the common complaints about git is the .git sub-directory containing a copy of the repo. It did take a little getting used to but frankly after a month or two we stopped worrying about it. Syncing is so fast and hard drives are so large these days one just doesn't notice the extra copies or feel a need to optimize or reduce. Though of course I still use NFS to distribute active sources to test machines so I can edit the sources on a stable machine.
Syncing mechanics are very flexible. Being able to both push and pull combined with ultra-fine branch management is a major win-win.
-Matt
Actually, that isn't quite true either. If the ISP end of the connection is taking a T1 then one entire channel is reserved for out-of-band signaling, leaving (I think) 23 64 Kbit channels available for modem connections. I remember there were two options available and to make 56Kbit modems work well we had to use the out-of-band signaling option, which reduced the number of phone lines we had on each T1 by one.
Direct T1s quickly became the standard for ISPs starting around 1994 ish, until T3's became cheap in '95 and '96. By 1998 most medium and large ISPs were splitting channels out of fiber directly, or had farmed their physical dialup to third parties which then backhauled them back to the ISP.
Phone companies also played their own games involving far more then an 8Kbit loss, but by the late 90's they could only use those tricks in places where they had insufficient physical copper to meet demand and they couldn't hide the fact that modems simply didn't work well with the line doubler technology they were forced to use in those places.
-Matt
I think one can say confidently that SSDs do not have the same near-term catastrophic failure issues that HDs have. A SSD will be about as reliable as, say, the motherboard in a computer. Certain parts within the SSD, such as electrolytic capacitors, have limited life spans, but no more limited then the electronics inside a hard drive. Many people in the server space talk about putting their boot partition on RAID to ensure that the machine is still able to boot with a failed hard drive. You don't need to do that if you use a SSD for your boot disk. Because the SSD is no less reliable then the motherboard it makes little sense to have additional redundancy in that context. Once you are booting from reliable media you have a lot more redundancy options for the rest of the media accessed by the machine. For example, there is no need to RAID the local disks within the local hardware, the redundancy can be networked instead.
However, the ability to recover from a flash that has been sitting on a shelf too long is a real issue compared to a HD. Both suffer thermal degradation over time but even if a HD's moving parts become unusable it is still possible to do a surface scan and recover the data after a long period of time has passed, even if it costs a few thousand dollars to do it. Once a flash cell leaks into the ether the data is virtually unrecoverable. There is nothing to scan. Theoretically one can shave the top off the chip and use a tunneling microscope to scan it (the Taiwanese did this to read out 'protected' EEROM from integrated cpu chips years ago), but the expense would be enormous, in the hundreds of thousands of dollars per unit or more, with no re-takes if it fails (the chip would be effectively destroyed). Flash-based media is NOT archival storage.
This is even more true for flash cells nearing the ends of their lives, after they've been rewritten a lot. The first write in a freshly minted flash memory will survive on the shelf far longer then the last successful write before a cell fails. The achilles heal of flash is the wear issue, and this limits its usefulness in server environments unless you explicitly replace the unit once a year as part of your regular maintenance. The risk is you put an often-used SSD on the shelf and a few years later the entire data set is corrupted beyond recovery.
On the flip side, your average consumer does not actually generate a lot of data. One terrabyte worth of writes on a 256G medium is only about 4 rewrites assuming perfect wear leveling, well within the 100,000 rewrites available. The AMOUNT of data is irrelevant. It's the amount of REWRITING that matters. We all know that the vast majority of the data sitting on those terrabyte drives is static. The problem is much reduced as the media capacity of the SSD increases. In a sense, the SSD problem is the same as the backup problem. Since you have to backup your machines anyway, your average rewrite bandwidth is limited by virtue of your backup bandwidth being limited. This would be true for most large data stores as well.
So it comes down to the price we pay per gigabyte. SSDs are clearly still way too expensive, particularly with HD capacities likely increasing past 10 Terrabytes in the next 5 years. SSDs simply cannot grow at the same rate as HDs, they are severely limited by fabrication issues that HD manufacturers do not have. The HD manufacturer can put an immense expense into the construction of the relatively tiny disk head if need-be without increasing the cost of the overall unit very much. The same cannot be said for the fabrication of flash memory chips.
SSDs have their foot in the door, though. The price really only needs to come down another 30% or so for the use cases to explode. This is still nowhere near the equivalent cost per gigabyte of a HD, but it doesn't have to be to gain mass acceptance. At some point in the next 10 years a new technology will pop up, perhaps it will be IBM's magnetic memory! Perhaps something else, that will solve flash memory's wear issues. When that occurs the mass acceptance will turn into an explosion of use cases.
-Matt
Right now the biggest problem ISPs have with bittorrent is not the bandwidth it uses, but the massive packet load it puts on their border routers, DSLAMs, etc. This is 99% due to allowing hundreds of simultaneous incoming connections. bittorrent clients have never been able to throttle incoming bandwidth aggregated across hundreds of connections very well, and the result is thousands of packets worth of backlog on the ISP's border routers, DSLAMs, etc, which blows them up.
Changing to UDP does not solve this problem, it just makes things even worse. The bittorrent people need to get their act together. The ISPs are just going to respond by changing their bandwidth filtering to be whole-IP-based instead of connection-based, and the result will be that people trying to use bittorrent will wind up with crappy, unreliable links for EVERYTHING they are trying to do over the internet.
I don't know why people using bittorrent should expect the ISPs to 'play nice' when they clearly don't give a damn about the mess bittorrent makes of the ISPs own infrastructure.
-Matt
If you hear a sound like morse-code in the speakers it's just the cellular phone transmitting something in close proximity to your system.
The problem isn't the cellular phone, it is simply that your computer's speaker cables and electronics tend to be unshielded. Sometimes the power cable itself is to blame, sometimes its the traces in the amplifier, but mostly it's the speaker cabling.
In any case, it usually doesn't take more then a $0.10 ferrite bead around the cables in question to remove the problem. That's why you often see ferrite beads built into monitor cables.
-Matt
I have to say, the ZFS folks have convinced me. There are simply too many places where bit rot can creep in these days even when the drive itself is perfect. The fact that the drive is not perfect just puts a big exclamation point on the issue. Add other problems into the fray, such as phantom writes (which have also been demonstrated to occur), and it gets very scary very quickly.
I don't agree with ZFS's race-to-root block updating scheme for filesystem integrity but I do agree with the necessity of not completely trusting the block storage subsystem and of building checks into the filesystem data structures themselves.
Even more specifically, if one is managing very large amounts of data one needs a way to validate that the filesystem contains what it is supposed to contain. It simply isn't possible to do that with storage-system logic. The filesystem itself must contain sufficient information to make validation possible. The filesystem itself must contain CRCs and hierarchical validation mechanisms to have a proper end-to-end check. I plan on making some adjustments to HAMMER to fix some holes in validation checking that I missed in the first round.
-Matt
The DragonFly project is planning on moving out of CVS and has been looking at various repositories. We aren't actually interested in Subversion per-say, not any more, but some of our developers have used GIT and a few are advocating for mercurial as well. We need to come to a decision by mid-november.
I haven't used Mercurial yet myself. I have used GIT. It took about a week to get used to it but once I understood the contextual labels things became a lot more obvious. We will maintain our central repository either by having it pull from the individual developer's repositories or by having the developers push into it. I'm still not quite sure what the best methodology is. It has to be automated no matter what.
If someone is using GIT in a similar manner I would like to hear your story.
I would also like to solicit opinions from people on GIT vs Mercurial.
-Matt
You can still buy HUBs for 10BaseT. Clearly nobody trying to use ethernet for a SAN is going to be using HUBbed 10BaseT.
Nobody in their right mind uses 100BaseT hubs unless they just want to sniff the port (since most dumb switches do not have monitoring features). I've never even seen 100BaseT hubs, do they even exist? Well, there's no reason to buy one anyway even if they do.
There has not been a cost basis for using a HUB for at least a decade. There's no point even arguing about it any more.
-Matt