error404

Member
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

0 Neutral

About error404

  • Rank
    Member
  1. error404

    TLER / CCTL

    The card I have in one of mine does allow me to adjust the setting it has to wait, and I want it to be short. My reasoning is simple, I want the drives to very quickly (< 5 seconds) abort with an error if they can't read/write a sector. I don't care if they can successfully read this sector after 20 seconds or not, the fact it is taking longer than 5 indicates something is wrong and that sector needs to be removed immediately, before problems arise. As you pointed out the controller doesn't know which block of data is bad if something doesn't add up, so I want the drive that is having problems to report so and move on, the controller will take care of fixing the data and it won't be ambiguous which block needs replaced. If you don't move on and let it just read and read it may very well finally read data, but it is likely corrupted anyways. Now we have exactly the situation you described, 3 blocks that don't add up and the controller is clueless as to which one it is. TLER lets me tell the drive, give it a few seconds in case something is weird, but abandon all hope very soon if it isn't working. Honestly having a controller babysit all drives and all commands in the NCQ and keep timing information on all pending reads/writes sounds great in practice an is just horrible in reality. The drives are not just spinning disks that hold data, they have on board electronics to take care of this kind of stuff themselves and they should be doing it. TLER is nothing more than a configuration variable, saying drives shouldn't support it is like saying controllers shouldn't have a configuration to control how long they wait for a drive. You obviously wouldn't argue that last point so I am curious as to why you seem to be pushing the first point. Also I would point out, I have a system where if I had to adjust the controller to wait 30 seconds because a bad sector developed in a drive would cause data loss. The RAID controller only has 1GB of on board write buffer and the CCD image capture that pumps live data onto this system produces data at about 70MB/s - that's 15 seconds of buffer space if the card is awaiting a drive because its having trouble writing a sector. Obviously this system is actually using expensive enterprise equipment and this isn't an issue at all since everything fully supports this kind of setup, but it is a valid example of situations where this could be a problem and shouldn't be. You are correct in that T13 has yet to publish all of ATA-8 (it is in a series of documents for different parts of the spec, some published and some working draft). Also I do like ZFS design, I was simply pointing out why I can't happen to use it in some cases. There are concepts of arrays and partitions in ZFS, it is only the top layer that hides all these behind the zpools. The level I am talking about is the actual vdevs being resized or reshaped, not the entire storage zpool. For now what I actually use its btrfs on top of a RAID6, I get the best of both worlds with this setup and someday btrfs should get the same kind of raidz like support to allow it to even handle software raid. Though one thing I am looking forward to in ZFS for one of my systems is raidz3, nothing else has triple parity so it will be the first I believe.
  2. Yeah, the PUIS is specifically for not doing a disk spin-up on power on (so cold boot generally). At 50 drives this would be a rather massive power draw, so I need to be able to sequence the spin up of the disks. Thanks again for the information though. I still can't believe samsung won't just provide me some sort of feature set list or something. All I needed was something like the output from hdparm -I or something, but they didn't seem to have any clue what I was talking about. Brian: Maybe you guys could include hdparm/smartctl information output in reviews and such or have a section of the site where people can go to submit them, it would make it easy to answer questions like the TLER and PUIS feature support
  3. error404

    TLER / CCTL

    I think you have some interesting arguments there, but I still disagree with your idea that somehow this is a controller only problem and not a drive issue. I think we actually agree on the final point though, the point is you should NOT need more expensive drives just to get a feature that should be in the drives to begin with but manufacturers are either disabling or ignoring to try and force people to buy more expensive drives. I also agree that for a regular user with a small array that having a controller that delays and waits on drives or could be configured to do so is an acceptable solution, but just because it works for a some doesn't mean this isn't a real problem for others and "ignoring it" isn't a possible solution when real data is on the line. My take on the same arguments is basically like this: Re: 1) Most controllers do, and I want mine set at 7 seconds so the array doesn't get locked up during heavy writes and begins dropping data when the write cache is consumed. (I have had this happen before in a high performance system... it isn't pretty) Re: 2) There isn't "elsewhere" to read the data from. RAID reads data in in stripes across all drives participating in the array, this is so reliability of data can be confirmed as well as having the necessary data should it be altered and parity recalculated. The drive needs to complete before the card can continue to do its calculations, this is what locks up the controller waiting for a response. Re: 3) We should reinforce choice in design, what you believe to be correct is apparently what I consider completely incorrect behavior. Good RAID cards allow me to specify what I want, the hard drive manufactures should not be dictating what terms I use their drives on. Re: 4) Actually there is a big difference between not responding and disconnected, not responding takes several attempts at communication and confirming the drive appears to be completely unresponsive. At that point it is considered the same as disconnected. Disconnected events can be tripped by the hot plug notification system instantly and the controller can cope with that much faster. In fact many cards do drop a drive because it doesn't respond fast enough. It took too long to respond (and some drives don't respond while they are doing something like attempting error recovery on a sector, exactly what TLER is supposed to fix) so its assumed the drive has lost power, been unplugged, the firmware locked up, any known host of problems. For data integrity the drive is knocked off the array. Also bad sector relocations, while automatic on the controller, absolutely send notifications of the problem encountered and it is in no way "hidden". This is precisely because drives developing problems reading/writing are very possibly going to fail soon, so the card can keep you apprised of this (obviously through some userland utilities). TLER simply allows the card to recover gracefully, timely, and make a note of the problem for someone to fix. On top of all that you shouldn't need a "more expensive" drive to fix the TLER problem. It is part of the ATA-8 spec, as far as I am concerned the drives claim ATA-8 compliance they should implement it. The "RAID Enabled" drives are a bunch of bull though, that is really the entire point here. Western Digital and others have tried to mark up the drive 50% when basically the only thing they change is effectively enabling the ability to control TLER. Supposedly they pick better batches and such too, but I am somewhat skeptical of any difference between the drives except for firmware locked features. I shouldn't need a new controller or more expensive disks, as far as I am concerned the controllers are doing everything the correct way and the drives should be obeying it, not the other way around. In terms of ZFS, until it supports resizable arrays it isn't an option for most of my projects which periodically require reallocating resources between machines.
  4. error404

    TLER / CCTL

    Here is my own personal rant as well: Actually there is a very good reason for TLER "tricks" and that is to fix the problem exactly as you describe. Lets say you have 10 drives running happily in a RAID6. These drives do not have TLER set to reasonable values and you have a RAID card expecting timely responses from your drives. Lets now say you have 1 drive have 1 bad sector suddenly. The card waits... and waits... and then drops the drive because it didn't respond fast enough. No big deal your trucking a RAID6 so your down to a RAID5 and a small performance hit. 15 minutes later a second drive develops a bad sector and is kicked out of your array... uh oh your down to an unprotected RAID. You get 2 new drives and swap out the (now failing) drives and start a raid rebuild... 15% in disk #3 develops 1 bad sector... is kicked out of the array. There went all your data. If only you had set a reasonable TLER so the disks stayed in the array, while they were failing in 8 months or so you had plenty of time to fix each of the failing disks without harming your data, but you chose to ignore TLER and instead lost 6TB of hard scientific data you had been collecting for a project. My point is it isn't a trick, it is a real world problem with a real solution. TLER for a desktop drive being high makes a lot of sense, you have no redundancy and the disk should try as hard as it can to get to that data before giving up. If you have a RAID where you have redundancy (1, 5, 6) then a single bad sector should not lock up the entire array trying to get 1 piece of most likely now bad data. Instead the controller opts to save on performance and the disk should just give up relatively quickly and the controller will fill in the missing data and relocate the bad sector data on its own.
  5. Thanks for the information. Do you know if PUIS is enabled via one of the jumpers on the back, or do I just need to issue an ata set feature command to enable it? In this case I have 20 drives (for now)... at power on they draw a lot of power, yet they draw 1/3 or less power during normal operation. I don't particularly want a power supply to suffer through the spinup power draw of that many drives which puts needless wear and tear on lots of components (even the drives themselves). If I only had 2 or 3 drives this wouldn't be an issue.
  6. Attempting to assemble a fairly large RAID for a NAS machine and I am trying to keep power-on requirements reasonable. I think the best drive option for my setup is Samsungs F3 EcoGreen 2TB drives - HD203WI - but I can't seem to find any information beyond the bare basics of the drive anywhere. Does anyone know if the drive support PUIS, either via jumper or ata set feature commands?