RobJ

Not this time ... Look at the fuller "picture"-- first, always be a little suspicious of numbers that are "all ones" (ie, 0x0fffffff); then look carefully at the preceding commands in the error log for the conclusive clue. --UhClem Oops, you are absolutely right. I didn't recognize that number in decimal. Not sure what to make of it though, need a lot more context, more of the code path to here. If you check his last SMART report, the 5 last errors show alternating like the above, then simple reads, then repeat. If I had to guess (and that is all I can do here), I would say there is a firmware issue. The LBA, even if it is 0x0fffffff, appears to be valid, about at the 137GB point. But in this small context, is probably a mask, and appears to be a part of an internal reset, possibly an internal crash? If my 'guess' is correct, then you cannot trust this drive. UhClem, I'd like to hear your opinion.

Those ARE the bad blocks, in more detail and only the last 5. UNC is short for UNCorrectable, so "Error: UNC at LBA = 0x0fffffff = 268435455" roughly means "bad block at 268435455". You probably got a typical response, from any manufacturing rep. But I would expect SeaTools to provide a similar report.

My guess is you received a drive with some problems, that had been 'repaired' by clearing the SMART tables, masking the problems, so the first test runs re-exposed the problems. The first 2 Preclears seemed to have dealt with most of them, and the third looks much better, but I'm not confident you've uncovered ALL of the marginal sectors yet. I'd run 2 or 3 more Preclears, and I'd only feel more confident if I had at least 2 passes with NO further changes, no more Current Pending sectors at any phase, no additional Uncorrectables, no additional Reallocated sectors. If interested and have time, you might also try a full badblocks run with the -w option. The other possibility is that it's a bad drive, and it's going to continue getting worse. I suspect that after another Preclear, you will either know it's bad or may decide that you aren't willing to trust the drive, even if it starts behaving, has clean reports.

The drive in first pic is troubling, shows 22 new bad sectors AFTER the Post-Read, not good. Preclear it again. Only if after another one or 2 Preclears it appears to be fine should it be considered safe to use. The drive in second pic looks older with some wear, but may be OK at the moment. We really need to check the SMART reports for both drives. All of the reports including the Preclear reports are in a folder on the flash drive. I don't remember the path, but it has 'Preclear' in the name.

no, they look great. Probably... only time will tell. So I should not be worried about the raw read error rate or spin retry count? Spin_Retry_Count = 100 100 97 near_thresh 0 End-to-End_Error = 100 100 99 near_thresh 0 I could not improve on Joe's response, as he was absolutely correct. Just a tip, if you are going to question the experts, it would be good to understand the subject matter first? As you can see above, the VALUE's for Spin_Retry_Count and End-to-End_Error are 100, could not be more perfect. The VALUE's for Raw_Read_Error_Rate for 2 of the drives at THIS moment are a little below 100, but are not a problem, they are still a long way from 44.

Like someone showing us their report card with all A+'s and all test scores equal to 100, you showed us your perfect SMART report indicating zero problems found and all VALUE's of 100 or better, and then you ask if anyone sees anything wrong??? I think most of us didn't know how to respond.

The 3 SMART reports look fine, except that the 2 new NAS drives got rather hot. Their temps rose from 25 to 41 which is quite a jump. I suspect they were installed somewhere without any airflow. Nothing wrong with the drives though. That's only a small fragment of the syslog, so hard to draw any conclusions. Whatever drive is sdf has a lot of bad sectors, and the drive sdd has found a single bad sector. I can't tell which drives those are without the earlier part of the syslog, but you can identify them from the UnRAID webgui.

Greetings and welcome! While the better funded users around here would probably respond that they prefer late model drives with pristine SMART reports, your 4 drives fit the other philosophy, of using UnRAID as a great place, a second life, for drives to retire to. Your drives do show some age and wear, but are still in very good shape, and the Preclears found no new problems. I would use them without hesitation. All but the first show a few remapped sectors, and one shows a higher than normal High_Fly_Writes count of 477, and one shows a lower than normal Seek_Error_Rate of 51, so I would monitor the SMART reports for these drives now and then, perhaps every few months?

If the disk controller was not compatible with 3TB drives, then it would not work at all, that is, you would not see 3TB available. Yours does appear to work fine. I can't see any connection with the motherboard, because we need a suspect that is able to cause corruption and trouble WITHIN the drive, and that is a very short list. The only possibilities I can think of are power issues, heat issues, or a defective drive (bad firmware). Remember that if you discover a relation between a software running and the drive crashing, then that could only point to heavy power draw (perhaps pulling the voltage down too low), and that implicates the power supply (not the software or other hardware), as either too inadequate or too poorly designed. Aerocool makes interesting products (I like some of their cases), but I don't believe they are a good name in power supplies (I could be wrong, I haven't kept up with PSU's recently). I can't help being very suspicious of your PSU.

Of Joe's 3 possibilities (bad power, bad cable, bad drive), I would have leaned strongly toward bad drive, except that you switched to a different drive! I see no evidence of a bad SATA cable, so I rule that out. Power issues seem very possible, except for some complications I will discuss later. Heat would be another possibility but SMART reports for both drives show only very cool temps. Bad disk controller or SATA port is a remote possibility, but it's one you can eliminate easily by switching to a different SATA port, and possibly a different SATA controller. The failures are all essentially the same, the drive times out (stops responding to a write request), so the Error Handler kicks in and resets the drive. The drive almost always responds very poorly or not at all to the first reset, then seems to respond acceptably on a second reset. It was only when the drive failed the second reset that the drive was disabled and dropped (at Dec 11 01:42:50). Errors after that can be ignored. The response to the first reset was usually no identity info at all, but if it did return identity info, then the data was found to include corruption. There are no CRC errors, so the drive itself must have created and sent these corrupted identity data packets! What is fascinating about these errors is that they aren't random, but appear to occur very close to a 30 second timetable. If you were to graph the occurrences, you would see a flat graph first then a sharp rise around 25 seconds, peaking around 30 seconds and returning to flat around 35 seconds. It would stay flat until another peak between about 55 to 65 seconds, then again around 85 to 95 seconds, and again around 115 to 125 seconds! It's hard to imagine a 30 second clock in the drive that could crash the drive. But it's also hard to imagine a power issue that occurs at roughly 30 second intervals. Is it possible that there is something creating a heavy power draw roughly twice a minute? Probably unrelated, but you might turn off Plex and any other drive related process, that includes any timer initiated processes. Sorry we can't help any more than that, but hope your testing can discover a cause.

'36' and '34808' aren't directly comparable, as 36 is essentially the scaled percentage of reallocatable sectors left, and 34808 is a count of the ones already used. The Value for Reallocated_Sector_Ct is 74, and that provides a rough way to calculate the number of available sectors. In this case, since 74 indicates that about a quarter of the total sectors have been used, you can multiply 34808 by 3 and determine that about 103,000 sectors remain. That should NOT however be a comfort, because 34808 is a rather high number, and indicates a high probability of something seriously wrong with the drive. All of the SMART numbers related to the mechanical condition of the drive look very good however. Uncorrectable sectors count (Reported_Uncorrect) looks rather high, but nothing like the Reallocated_Sector_Ct. The Preclear caused all of the suspicious sectors (Current_Pending_Sector) to be recovered, with none requiring remapping, but then found 8 more! That's a bad sign. The only 2 causes I can think of are (1) a large area with marginal magnetic media (weakly magnetized) or (2) a source of shorting (or other bad electrical noise) in the drive that is corrupting sectors. I personally would not trust this drive. You can Preclear it one more time, but I expect to see more instability in the Current_Pending_Sector count, and that is unacceptable. It's a commonly run tool, and likely to be requested by Seagate reps, but (unless something has changed) requires the drive to be attached to a Windows machine. I doubt you can return this drive, outside of its enclosure.

Well, the good news is the drive is probably fine, but unfortunately, there was a serious error in the interface between the drive and the system. My best guess is an issue with either the driver module or the SAS controller, but there does not appear to be any better info as to what the specific problem was. You started the rebuild at about 6:26pm, and less than 8 minutes later the SAS subsystem reported trouble. When it tried to hard reset the device for the drive, then the device stopped responding completely, and was disabled by the kernel, only 18 seconds after the problem first appeared. You can completely ignore all of the subsequent errors, as the drive was essentially not present once disabled, and the higher level write routines were not aware of that. A side issue, of unknown significance, a possibly critical error was logged, probably related to the installation/initialization of the open_vm_tools package. I have no relevant expertise here, perhaps someone else can help? It may be harmless...

The report looks good except I don't like the High Fly Write value. I concur. It's strange to see a brand new drive with 93 High_Fly_Writes already, and no other adverse numbers. It could possibly be a faulty sensor, but I'd monitor this drive more than normal, because it *may* have mechanical issues that will shorten its lifetime. But so far, I have never heard of any drives that have failed, whose only SMART warning was a large number of High_Fly_Writes, so we don't want to unnecessarily alarm you. Right now, the drive is fine, and may be fine for years, but I would not be surprised if this drive failed sooner than others of the same model.

Really need to see the whole syslog, your syslog piece indicates there should be a long series of errors before. Generally, it's the very first error that is the most important, but in your case you can see a 'media error' with 'UNC' flag (UNCorrectable) raised, so you have had a read error on the drive. The drive itself is reporting it. The buffer errors you see indicate there were more prior to this. Dealing with them is what is slowing processing way down. I think the Post read may be still working, even if very very slow. I don't understand that SMART report piece, seems completely inconsistent with the syslog piece. Are you absolutely sure it's from the correct drive, and that it is current? Current_Pending_Sector count should have increased, and possibly also Offline_Uncorrectable (except it's not offline testing). I have to work now, but others can help...

There were no lost packets detected, or any other disk errors. That was just my speculation about a possible linkage between the resetting of the card for recovery of one attached drive that somehow affected the I/O of another attached drive. Resetting should be completely transparent and safe, and it *was* transparent in that operations continued without issue to the other drives (except for a small delay). But in this case, something caused file system corruption, at essentially the same time as the resetting and disabling of the other attached drive. It seems linked to me, but I don't have an actual error or fault to point to, just a bit of speculation. It's usually always hard to say for sure. The SMART wiki page says about Multi-Zone Error Rate: "The count of errors found when writing a sector. The higher the value, the worse the disk's mechanical condition is." It associates a higher Multi-Zone Error Rate with deteriorating mechanical condition. I would not be surprised if the drive sounds noisier than the others. That's part of the exception handler for drive issues, and that's probably a local address within it. If you really want to know, you'll have to research that yourself, somewhere within the Linux kernel source code, possibly libata.c or wherever the ATA exception handling code is.

Short drive history: (SAMSUNG HM100UI, 1TB) First PreClear started at Jul 7 19:03:31 2013 PDT, Power_On_Hours = 5147. Pre Read took about 7 hours (39 MB/s) Zeroing took about 53 hours (5 MB/s), indicating probable issues Post Read took almost 17 hours (16 MB/s) Final SMART report could not be obtained, indicating drive was lost, so Post Read may have aborted Later SMART report indicates 24 Pending sectors, may have been found during this PreClear SMART short test was run at Power_On_Hours = 5742, indicating possible drive issues at that time, but short test found no issues. Second PreClear started at Aug 18 21:03:38 2013 PDT, Power_On_Hours = 6157. Pre Read took about 4 hours (69 MB/s), may have aborted (so speed is suspect) Zeroing aborted almost immediately, indicating drive was lost Post Read did not occur, drive not present Final SMART report could not be obtained, indicating drive not present At Aug 19 01:02:59, the kernel lost communications completely with the drive. It tried repeatedly to recover the drive, to reset the SAS card, but failed, and only 20 seconds later marked the drive as lost ('disabled'). You can completely ignore all subsequent errors from this drive, because from the kernel's point of view, the drive is no longer present. When a drive is lost this way, you cannot conclude where the fault is, whether of the drive or the SAS card or the cable or power issues or the driver etc. The drive does appear to be having problems, but they may not be related to the loss of communications here. I believe it happened with both PreClears you ran on this drive, during the current Pre Read and during the Post Read of the earlier PreClear. Part of the confusion here is that PreClear failed to notice that the drive had failed, and proceeded with final reports anyway, basing them on incomplete info. SMART info on this drive is rather odd. The only 3 attributes marked as critical are either perfect or very good. The Multi_Zone_Error_Rate has bottomed out with a VALUE of 001 and count of 53348. If it had considered that to be a critical item, the drive would be considered FAILED, but the manufacturers seem to have stopped marking new SMART attributes as critical any more. Calibration_Retry_Count has a VALUE of 046 and count of 55072, which similarly looks very serious to me, but its SMART controller does not seem too worried about it. If you still want to use this drive, I would move it to a motherboard SATA port, use a different power cable, and try PreClearing it again. I personally believe you should consider the drive as failed, unreliable, and not use it. Joe L, I can't help being concerned about PreClear here. It failed to notice that a drive was lost, that a Pre Read had aborted, that a Zeroing failed to start, that a Post Read may have aborted, and that the final SMART report could not be obtained. Could I respectfully request you recheck how error returns are being handled? Perhaps some additional checks for the continuing existence of the drive are warranted. This occurred only a minute after the resetting and disabling of the PreClearing drive sdh. I would not normally associate a physical drive issue with a file system issue like this, but it seems too coincidental not to in this case. I also note that the same SAS card has sdh, md12, and md13. Disk 13 did not show any issues. It is possible that the resetting of the SAS card caused a lost packet that was being written to Disk 12 (md12). The only other cause I can think of is a strong power spike that affected both sdh and md12, except sdh had had a similar loss of comm during its earlier PreClear. As you can see above, once the Reiser file system detected corruption in the file system, it remounted it as read-only, blocking any further modifications until after rebooting. You will need to run Check Disk File systems on Disk 12.

You are right to be concerned, RMA it ASAP. Initial SMART report looked fine, but the subsequent one showed that the critical attribute Raw_Read_Error_Rate has bottomed out, far below its threshold value. Send it back, with a copy of that last SMART report. Drive is already considered failed, according to its SMART system, even if it appears to be working somewhat.

Just my opinion, and not an expert one at that, I don't see any evidence that those number changes actually relate to real physical errors. The Preclear pass times look quick for a relatively slow drive, so no indication of any slowdowns while testing marginal sectors. There are no Preclear failures, the zeroing and post-reads are successful, so no indication of any hard drive problems. SMART reports no remapped sectors at all, no SMART errors in its log, and all critical attributes appear near perfect, or at least error-free. And the number changes seem to fit a software pattern, not a random hardware pattern as you would expect. It's hard for me not to feel that the firmware is either buggy, or has been corrupted, which is why I suggested a check for a firmware update, admittedly a long shot. If the subsequent Preclear is similar, then I don't know what to advise, because while I feel the drive is probably physically fine, buggy or corrupted firmware or SMART subsystem makes the drive somewhat untrustable.

Very interesting drive. It is not behaving in a standard way, so my comments should be treated as low confidence, as I've never seen a drive like this. Current_Pending_Sector count did not change, did not increase because long test does not write, but I was hoping it would drop, perhaps even clear completely. Reallocated_Event_Count increased by 58, yet there are no remapped sectors and no logged errors. Offline_Uncorrectable increased by 112. Your previous Preclear caused Current_Pending_Sector count to increase by 112, Reallocated_Event_Count to increase by 183 (an average of 61 per Preclear pass), and Offline_Uncorrectable to increase by 336 (112 times 3, 112 per Preclear pass). It's very difficult to trust this drive, but I can't actually say it's bad, with no errors logged and no critical attribute values (those marked Prefail). Try one more Preclear. You might also look for a firmware update from Samsung.

I can't help being a little suspicious of these SMART numbers. Attributes 196, 197, and 198 are all increasing by significant amounts, yet there are no remapped sectors and no SMART errors logged. It says 375 hours on the drive, is that plausible? I note that it indicates there have been 3 times as many power cycles of the drive as there have been operational hours. That is, for every hour it has been on, it thinks it has been turned on 3 times each hour?!? I suppose that is possible if this was in a laptop used for a number of short sessions (turn on, check email, turn off), or perhaps aggressive power-saving (quick turn off of hard drive when idle). I recommend running a SMART long test, to see if it will reset some of the SMART attributes. Then post a subsequent SMART report. If we can get it to reset, and it looks OK, then you will need at least one more Preclear before you can trust this drive.

Perhaps I could help with that? I've started a page, very incomplete yet, but does have comments specific to the Raw Read Error Rate. A comment about the High Fly Writes attribute - ignore the VALUE and WORST for this attribute. I believe it has a dummy routine attached to it, because in all cases I have seen, it behaves like the following: ++RAW[189]; // it's a counter for high fly writes if (VALUE[189] > 1) --VALUE[189]; // decrement for each event (drops it from 100 down to 1), but no lower than 1 if (WORST[189] > VALUE[189]) WORST[189] = VALUE[189]; // the usual statement setting WORST to the lowest value of VALUE RAW appears to be the true counter of High Fly Write events. VALUE then becomes 100 - RAW until RAW exceeds 99, and then VALUE and WORST are stuck at 1, and never can reach THRESH of 0. That's why I believe it is an experimental attribute and this is a dummy routine, and should be ignored. However, the fact that there are High Fly Writes occurring may be of note, should probably be monitored, but we have no guidance anywhere as to their significance.

I'll bet you don't like pass/fail idiot lights in cars! You probably prefer gauges and reports that provide much more technical info, but also require much more learning to interpret! The problem here is that SMART reports contain a LOT of info, presented in unusual ways, with a definite learning curve, and most users aren't that interested. They just want to know if the drive is good, or needs to be replaced. For now, I'm going to suggest reading back a ways through this thread, and you will find a number of scattered posts that explain various numbers. Joe has often answered specific questions about various SMART numbers. I've begun a wiki page called Understanding SMART Reports that should help, but it is far from complete.

I estimate the files that I have cached are just under 6000, a lot to me but obviously trivial compared with others here. My results : * 25247 seconds - parity check with CacheDirs, network disconnected * 25462 seconds - parity check without CacheDirs, network disconnected * 25532 seconds - parity check without CacheDirs, network connected, 2 CPU stalls * 25335 seconds - parity check with CacheDirs, network connected * 25740 seconds - parity check without CacheDirs, network connected, 3 CPU stalls, backup to server ran Clearly, almost insignificant differences, but I cannot see any thrashing impact from CacheDirs running. A little thrashing may be evident in the final result when a 4am backup to my UnRAID server was run. When the network is connected, there were 3 to 5 refreshes of UnRAID web page, plus the constant (5 minute) polling of server folders by SageTV, which may explain the slightly longer times for network connected results. An additional note, after the second test and after all drives had spun down, with no CacheDirs running, I reconnected the network cable, partly expecting to see the drives spin up once SageTV checked all of its server folders. None of them did. So I forced SageTV to do extra checking for any changes in video folders, and again not one drive spun up. That tells me that the entire parity check process had not caused the loss of a single dentry, even without CacheDirs to protect them. I had to tell SageTV to view a video (just to make sure it was working!), and one drive spun up. Another note, rather odd, I have never before seen a single CPU stall error with call trace before. Several happened on both runs (all on CPU #1, all within the first 20 minutes only) with network connected (obviously normal!) but no CacheDirs (not normal for me). I always have CacheDirs running. It is tempting to think that CacheDirs not only protects my dentries, but also protects me from CPU stalls! I have no idea what to conclude from that.

Initial result, parity check with CacheDirs running took 25247 seconds, parity check without CacheDirs took 25462 seconds. The difference may not be statistically significant, .0085% longer (I think), but does not indicate a CacheDirs impact. The first test with CacheDirs running was immediately after a fresh boot, so it is possible that someone might claim a fresh system advantage that the second test did not have, but it is hard to imagine any advantage maintained over the long check process. In any event, I'll be happy to repeat it to rule that out, if anyone wants. I've started a new parity check (CacheDirs still off) with network cable connected, thereby enabling any polling by my SageTV on another machine. This should be similar to those of us with media players/managers or other external process(es) that periodically poll folders on the server. Then I'll run one more test with CacheDirs re-enabled, network connected. My tunables are relatively standard, with 1GB of RAM: md_num_stripes 1280 md_write_limit 768 md_sync_window 384 I believe my vfs_cache_pressure is 0, which is what I have preferred since I have never ever had an OutOfMemory condition, but I'm unsure of how to obtain the value of vfs_cache_pressure. If someone can give me the command, I'll verify it. Jun 22 16:06:33 JacoBack emhttp_event: svcs_restarted Jun 22 16:07:00 JacoBack init: Re-reading inittab Jun 22 16:09:00 JacoBack cache_dirs: command args=-w -m 3 -M 3 -a -noleaf -i Vid*, version=1.5r Jun 22 16:09:00 JacoBack cache_dirs: max_seconds=3, min_seconds=3, max_depth=9999, command=find -noleaf Jun 22 16:09:00 JacoBack cache_dirs: VidLib3,VidLib4,Videos,Videos1,Videos2,Videos3,Videos4,Videos5,Videos6,Videos7,Videos8,Videos9, root_dirs Jun 22 16:09:01 JacoBack cache_dirs: cache_dirs process ID 1515 started, To terminate it, type: cache_dirs -q Jun 22 16:11:09 JacoBack login[1522]: ROOT LOGIN on '/dev/tty1' Jun 22 16:11:40 JacoBack kernel: mdcmd (49): check CORRECT Jun 22 16:11:40 JacoBack kernel: md: recovery thread woken up ... Jun 22 16:11:40 JacoBack kernel: md: recovery thread checking parity... Jun 22 16:11:40 JacoBack kernel: md: using 1536k window, over a total of 1953514552 blocks. Jun 22 16:11:48 JacoBack kernel: skge 0000:01:04.0: eth0: Link is down Jun 22 18:20:42 JacoBack kernel: mdcmd (50): spindown 5 Jun 22 18:20:43 JacoBack kernel: mdcmd (51): spindown 7 Jun 22 18:43:44 JacoBack kernel: mdcmd (52): spindown 6 Jun 22 19:41:28 JacoBack kernel: mdcmd (53): spindown 1 Jun 22 19:41:28 JacoBack kernel: mdcmd (54): spindown 3 Jun 22 20:14:30 JacoBack kernel: mdcmd (55): spindown 8 Jun 22 21:24:46 JacoBack kernel: mdcmd (56): spindown 2 Jun 22 21:24:47 JacoBack kernel: mdcmd (57): spindown 4 Jun 22 23:12:28 JacoBack kernel: md: sync done. time=25247sec Jun 22 23:12:28 JacoBack kernel: md: recovery thread sync completion status: 0 Jun 22 23:43:42 JacoBack kernel: skge 0000:01:04.0: eth0: Link is up at 1000 Mbps, full duplex, flow control both Jun 22 23:54:58 JacoBack emhttp: Spinning up all drives... Jun 22 23:54:58 JacoBack kernel: mdcmd (58): spinup 0 Jun 22 23:54:58 JacoBack kernel: mdcmd (59): spinup 1 Jun 22 23:54:58 JacoBack kernel: mdcmd (60): spinup 2 Jun 22 23:54:58 JacoBack kernel: mdcmd (61): spinup 3 Jun 22 23:54:58 JacoBack kernel: mdcmd (62): spinup 4 Jun 22 23:54:58 JacoBack kernel: mdcmd (63): spinup 5 Jun 22 23:54:58 JacoBack kernel: mdcmd (64): spinup 6 Jun 22 23:54:58 JacoBack kernel: mdcmd (65): spinup 7 Jun 22 23:54:58 JacoBack kernel: mdcmd (66): spinup 8 Jun 22 23:54:58 JacoBack kernel: mdcmd (67): spinup 9 Jun 22 23:56:32 JacoBack cache_dirs: killing cache_dirs process 1515 Jun 22 23:57:56 JacoBack kernel: mdcmd (68): check CORRECT Jun 22 23:57:56 JacoBack kernel: md: recovery thread woken up ... Jun 22 23:57:56 JacoBack kernel: md: recovery thread checking parity... Jun 22 23:57:56 JacoBack kernel: md: using 1536k window, over a total of 1953514552 blocks. Jun 22 23:58:04 JacoBack kernel: skge 0000:01:04.0: eth0: Link is down Jun 23 02:09:44 JacoBack kernel: mdcmd (69): spindown 5 Jun 23 02:09:44 JacoBack kernel: mdcmd (70): spindown 7 Jun 23 02:32:55 JacoBack kernel: mdcmd (71): spindown 6 Jun 23 03:30:39 JacoBack kernel: mdcmd (72): spindown 1 Jun 23 03:30:39 JacoBack kernel: mdcmd (73): spindown 3 Jun 23 04:03:41 JacoBack kernel: mdcmd (74): spindown 8 Jun 23 05:14:37 JacoBack kernel: mdcmd (75): spindown 2 Jun 23 05:14:38 JacoBack kernel: mdcmd (76): spindown 4 Jun 23 07:02:11 JacoBack kernel: md: sync done. time=25462sec Jun 23 07:02:11 JacoBack kernel: md: recovery thread sync completion status: 0 Jun 23 08:02:19 JacoBack kernel: mdcmd (77): spindown 0 Jun 23 08:02:20 JacoBack kernel: mdcmd (78): spindown 9 Jun 23 09:25:22 JacoBack kernel: skge 0000:01:04.0: eth0: Link is up at 1000 Mbps, full duplex, flow control both

Your explanation helped me see that I've made a couple of assumptions which may or may not be true. One is that the caching of directory entries is completely separate from the general data buffers. I had thought that the existence of the dentry cache implied that they were managed separately, and no amount of disk thrashing (apart from directory loading) would ever flush them. This may or may not be so, and I'll happily learn from the true kernel experts here. The other assumption was based on my predilection as to the most efficient way to do a parity check operation. If I had programmed it, based on the principles of earlier OS's, I would have assigned a single buffer per drive, plus a few work buffers, and simply reread into them while cycling through the blocks. But of course, modern I/O systems are layered, and you can't get as close to the hardware now, so additional disk buffering may be happening at lower levels than my read requests. But I still can't help thinking (more assuming here!) that the disk I/O from the parity check is all at a lower level than the file system buffering, and therefore is not flushing anything that is filesystem related. I'll await correction from the more knowledgeable here. At any rate, it seemed wise to run my own test, so I have started a parity check. I disabled SimpleFeatures, and made sure the system is relatively clean, only powerdown and UnMENU and CacheDirs, and restarted the server. I started the check, then immediately disconnected the network cable, to disallow all external disk access. I'll monitor a tail on the monitor to know when it's done. Then I'll disable CacheDirs and rerun again the same way. Unless I've forgotten something, that should be a fair test.