Q: Mavericks corrupts external hard drive

Nor have I. Or nor will I. I was just trying to clear that link up for any Daredevils who wish to ever put any WD software back on their Mac. I have never touched it, which may, and I repeat may, have been the reason I had no issues with my drive.

But thanks for posting a working link for other users here.

Cheers

Pete

Dear All

Hopefully this is some help (I had posted last week here with my concerns too). I have three WD drives - all different buidls and ages. We run several Macs (iMacs) from 2011 machines to late 2013 ones.

I have tested all the WD drives (no WD software installed, as never seen the use for it) and the two that have it are behaving fine under Mavericks so far. All I'd add is that we still have two Macs on 10.6.8 and one on 10.8. and the FW drives were all formatted and backed up under these OSs. When plugged into the new OS on both Macs all data is correct and present.

The only third party BU software that has been installed on the newest 2013 Mac is a copy of Memeo Back up (version 2.5 (144)) which shipped with the oldest WD drive and was pretty good bundled software - though now is possibly needing update/compatibilty attention from Memeo - who I have been in touch with re. this forum and my concerns with our set up. They are being very helpful too but only regarding their own software and Mac OS 10.9. They say they are a partner of WD on their site but have not acknowledged any isues.

I find their software easy and reliable - basically that's exactly what it should be! It's also not "approved" by Apple's store yet but then it's not on the App store anyway, it's purchased 3rd party. I ran a small risk I felt as I wanted to road test it on a brand new Mac, OS and drive for the back up. Granted, most of you are not in that position, but at least this is one "clean" test on a new set up to judge a few things on. i.e. no interferance from older software, firmware etc.

So for the techs out there puzzling all this, here's some of our set ups tested:

iMac 2011 (late) 10.9 (installed 2 weeks ago)

WD FW400 1TB MB Studio

WD FW800 2TB

Adobe CC, MS Office 11 etc all on there

All seemingly OK still via USB2 on the 2TB (though still need to plug in via FW on one drive and see if it affects data loss)

iMac 2011 10.6.8

WD FW800 2TB MB Studio

Main workstation

All seemingly OK when checking drive plugged into 10.9 machine and back again to older Mac/OS 10.6.8

iMac (late) 2013 brand new install of OS 10.9

Adobe CC installed (only so far)

Brand new WD USB3 Passport for Mac (2TB) formatted on this mac with disk utility as recommended.

Installed Memeo BU sotware (from downloaded DMG from their support pages) Registered again with our serial, as it was a paid for product before. Set up back up plan and so far so good. That was this morning. BU running still copying from a NAS drive on network via ethernet.

If any of the above changes, I'll report back in. If of course anyone wants to let me know this is useful or just muddying the issue!! I'm not trying to be unhelpful by the way, just sharing my findings.

To be honest, I'm not Mavericks biggest fan so far either, as they seem to have dumbed down some features (well some important features since Lion came along) so going back a step for me wouldn't be a killer. Also, the ability to sync devices can only be done via iCloud? Hopefully that's a slip up they will rectify soon! Choice to use cloud services or not must not be taken away from users. Sorry that's another post.

Thanks for now....

PlotinusVeritas wrote:

... however what needs to be addressed, and you have not commented upon, as stated, are those HD (RAID [seagate mostly] and otherwise) which experience total data loss and are not being repartitioned EFI/MyBook

That's because there isn't enough data provided to do anything other than make wild guesses about the cause. But, as you yourself mentioned, it is not something everyone is experiencing, which suggests that the cause may well be something other than Mavericks itself, just as it now seems very likely that the old WD software is when it is present on the system.

And there are almost certainly several different causes, each with different characteristic symptoms, being discussed here. For instance, some users are reporting mounting problems; others are not. Some are reporting file system issues that Disk Utility can't fix; others make no mention of that. Some users say they have not installed any WD software, yet their drives have been repartitioned with the characteristic "MyBook" partition name, which can't plausibly come from any other source.

Beyond that, we can't rule out the possibility that for some users other third party additions to the system besides the WD software are at fault, either individually or in some combination that causes them to conflict with each other. We also need to consider cases where a drive may have been unmounted incorrectly, for instance because of a loose cable or sudden power failure. (Both have happened to me from time to time.)

My point here is that lumping all these reports together without regard for the details that differentiate them from each other & concluding that Mavericks itself somehow is always the cause doesn't make much sense. Postulating vague theories about that doesn't help; as you said yourself, what we need is better data, not more speculation.

You didnt answer, -- what is your conclusion, if any, of:

• "an obvious fault in the node structure where fsck was commanded to diagnose the HFS (OSX ext. journl.) journaled file system"

My conclusion is whoever wrote that is just stating one of the things fsck has always checked, as if it was something something new or suspicious. And I can find no instance at all of anyone posting that comment exactly as quoted anywhere searchable on the web (besides of course your mention of it here in this discussion).

The only hit I get for anything very similar is http://www.windchilde.com/bluedepth/. That does match what you said you remembered about someone experiencing data corruption while moving data files, but there is no mention of it being a repeatable occurrence. Besides, this blogger is clearly not a drive technician of any sort, much less a WD one. He is just someone speculating about possible causes of a couple of drive-related issues he has experienced, one with Mavericks & one with Mountain Lion.

Regarding quoting in general, it would be very helpful & much appreciated if you could be careful that what you include in double quotes is actually a direct quote & that any stated attribution is as accurate as possible. It would also be helpful if you could quote enough to make the context clear & clearly separate your interpretation of its meaning from the quote itself. As it is, with all your style embellishments & short, unattributed quotes, it is often impossible to tell if you are quoting something or not, or how it applies to the discussion.

In case you haven't yet figured out how to use this forum's non-intuitive quote mechanism, in a reply you can select one or more paragraphs you have entered & click on the quote button (looks like a speech balloon with a double-quote mark to one side) in the reply editor toolbar. That formats it as above, inside a box that makes it easy to tell at a glance that it is a quote.

I have now used 2 WD bare drives in my own enclosures and have had no issues with TM.  All backups are completed as scheduled and no corrupt files.  I did have to be sure that my WD drive does not sleep by using the "keep drive spinning" app as just checking off the box in the energy preferences has no impact on the drives.  I did this because I found at times if the drive is asleep then TM will not always wake it up when required.

2Leigh wrote:

All I'd add is that we still have two Macs on 10.6.8 and one on 10.8. and the FW drives were all formatted and backed up under these OSs ...

That reminds me of something that might be of interest for those with more than one WD brand external drive that originally came formatted for OS X & were not reformatted by users before being put into service:

Several users have confirmed that some of these WD "My Book" drives were formatted with exactly the same UUID (Universal Unique Identifier) at the factory. This is a very serious problem if you have more than one of these units attached to your Mac because the UUID is how the OS distinguishes one drive from another. (For example, it is why you can rename a mounted drive without confusing the OS.)

Normally, UUID's are assigned individually during formatting using an algorithm that insures they are in fact unique but apparently some of the WD drives were formatted using some mass duplication method that did not do this. It isn't known how many drives are involved, only that the ones that are were bought at different times from different sources & (probably) came from different WD factory lines.

What is known is the HFS+ partition UUID in every case is 2CA31A4C-9B24-3F7D-A7A2-4B168E43FBBE. (See for example Help! Multiple Hard Drives with Identical UUIDs! in the Mountain Lion forum for more about this. Users with a level 6 or higher rating can also access a longer discussion in the "Lounge.")

Please note that if you only have one WD external drive, or if you formatted it yourself with Disk Utility or any other utility that uses a standard algorithm for assigning UUID's, you are not affected. But otherwise, there is a high risk of data corruption when both drives are attached to one Mac at the same time (because the OS will randomly read from & write to either drive since it can't tell them apart). This has nothing to do with the OS X version in use -- in fact any OS that uses UUID's to identify drives will have the same problem.

You can check the UUID of the partition(s) of your drive(s) using Disk Utility. In the First Aid tab select a partition from the list on the left & click the "Info" button in DU's toolbar (or select "Get Info" from the "File" menu). In the info window that pops up you will see about half way down an entry for its Universal Unique Identifier.

If you do have only one WD drive with the above UUID, you don't have to do anything about it other than be aware that if you buy another one, it might have the same UUID, so before using it you need to disconnect the one already in use, mount the new one & check its UUID. If it is the same, reformat the drive using DU's Partition tab, which will give it a new UUID that is actually unique.

But if you have more than one WD drive with identical UUID's you need to reformat at least one of them, which will erase all its data, so you need to back up its contents to another drive before doing this.

Thanks RCR, that's an interesting note to check this out then. Though the drives are very rarely together on one Mac but will see what I can do with these UUIDs.

BTW, I just had this response from the Memeo Back Up people (if anyone else uses their BU software)

Doesn't sound like a thorough test does it!? But....

Note the "drive mounting correctly" comment. This does sound like the crux of it, recalling what most are saying here. Apologies but I haven't read back through the last week's posts yet, if this is old news, just remembering what was written prior.

Thanks

Leigh

Well count me in as a casualty of this one. I was chasing this down as a possible issue with my hard drive enclosure. Here's a post a made to the Mediasonic forums about their 4 bay enclosure and I'll report back if they say anything meaningful:

I have two HF2-SU2S2's and each contains 4 2TB drives configured as JBOD (one enclosure is just a back up for the other) - I connect these to my Mac running Mavericks 10.9 and all is working great. However I've run out of room, so I purchased two WD Red 3TB drives (WD30EFRX to be precise). I put these two new drives into a separate enclosure (not the HF2-SU2S2), formatted them (as Mac OS Extended Journaled) and copied the contents of one of the 2TB drives onto both of the 3TB drives (which took 24 hours!!). After that, I opened up one of the HF2-SU2S2 units and replaced the 2TB drive with the 3TB drive, closed it up and connected it to my Mac. When I did that the Mac had all sorts of problems with only the 3TB drive and said it had issues and needed to be repaired. I did that using Disk Utility and that failed. I then put the drive back into the enclosure that I originally formatted it in and it was broken there too (I guess Disk Utility mangled it when I tried to repair it). The remaining 3TB drive that I didn't put into the HF2-SU2S2 still works just fine in the other enclosure.

So my question is - did I do something wrong? The HF2-SU2S2 is supposed to support up to 4TB drives. Is there a firmware update the enclosure needs? Does the HF2-SU2S2 support WD Red 3TB drives?

I was able to get the Seagate 3T to fail to mount again after inserting the FW800 cable at 9:59. I waited for fsck to begin checking the drive and launched Disk Utility and clicked on Repair. As I suspected, Disk Utility “interrupted” the ongoing fsck and quickly concluded that “Disk Utility can’t repair this disk….” along with it's normal dire warnings to recover as many files as possible blah, blah blah. So I patiently waited for the original fsck to continue it’s check and the disk mounted! You guessed it - 8 minutes after the initial mount attempt.

Here is the fsck_hfs log…

/dev/rdisk1s3: fsck_hfs started at Wed Nov 27 09:59:33 2013

/dev/rdisk1s3: /dev/rdisk1s3: ** /dev/rdisk1s3

/dev/rdisk1s3:    Executing fsck_hfs (version hfs-226.1.1).

/dev/rdisk1s3: ** Checking Journaled HFS Plus volume.

/dev/rdisk1s3:    The volume name is Seagate 3T

/dev/rdisk1s3: ** Checking extents overflow file.

/dev/rdisk1s3: ** Checking catalog file.

/dev/rdisk1s3: fsck_hfs started at Wed Nov 27 10:01:05 2013

/dev/rdisk1s3: /dev/rdisk1s3: Can't open /dev/rdisk1s3: Resource busy

/dev/rdisk1s3: fsck_hfs completed at Wed Nov 27 10:01:05 2013

/dev/rdisk1s3: ** Checking multi-linked files.

/dev/rdisk1s3: ** Checking catalog hierarchy.

/dev/rdisk1s3: ** Checking extended attributes file.

/dev/rdisk1s3: ** Checking multi-linked directories.

/dev/rdisk1s3: ** Checking volume bitmap.

/dev/rdisk1s3: ** Checking volume information.

/dev/rdisk1s3: ** The volume Seagate 3T appears to be OK.

/dev/rdisk1s3: fsck_hfs completed at Wed Nov 27 10:07:35 2013

At the same time as the original fsck completed, the sys log read…

Nov 27 10:07:35 GetRealBros-MacBook-Pro kernel[0]: jnl: disk1s3: journal start/end pointers reset! (jnl 0xffffff803a1ed5a0; s 0x2b6a000 e 0x2b6a000)

Nov 27 10:07:35 GetRealBros-MacBook-Pro kernel[0]: hfs: mounted Seagate 3T on device disk1s3

So at least one lowish level disk utility can attempt to interrupt a “fsck on mount” while it is still running. And as a result it can get the wrong answer! I wonder how many other disk utilites/drivers can make this same mistake? And I wonder whether they might then take the wrong action? OOPs.

But of course this is just a personal problem on one drive. It just “doesn't make much sense” to think that the piddely mounting problem that I’ve been documenting might be linked to the other reports in this thread of more serious external drive problems

—GetRealBro

R C-R wrote:

~That's because there isn't enough data provided to do anything other than make wild guesses about the cause....

~Mavericks itself somehow is always the cause doesn't make much sense...

~Postulating vague theories...

(since you like quote bubbles)

That statement is Skepticism,.. in fact if yourself or another can dissect the release from WD that was posted yesterday and determine what changes have been made in contrasting the two packages, it could be determined what the causation (or binary) is.  Obviously WD will not release such information openly.

I specifically have not directed  sole causation at or towards Mavericks, ...so that is a fallacious statement, maybe however you were referring to someone else.   All evidence points to, as stated, binary causation as most plausible,    since the locus of change was Mavericks in the case of non-WD drives. However in cases of 'legacy WD software' on these drives, would not explain OSX restores where occurrence was duplicated by a few in this thread.

I have not postulated a "vague" theory, rather a  logical one based upon the limited given evidence. Its classical Sophistry to posit that you "cannot forward a theory with less than 100% empirical proof", ...which thereupon, there would be no NEED of a theory at all, at that point it would be a fact. Relativity is still a "theory" by definition as well as action at a distance (ala magnetism) is a "theory", neither are 100% fact.

I have already found 5 mentions of fsck being run on a HFS+ Journaled system which should NOT be being run according to developers

one being:

A: /dev/rdisk1s3: fsck_hfs started at Tue Nov 26 08:12:11 2013

/dev/rdisk1s3: fsck_hfs completed at Tue Nov 26 08:20:08 2013

That is 8 minutes of FSCK on an external Seagate Firewire HD

"an obvious fault in the node structure where fsck was commanded to diagnose the HFS (OSX ext. journl.) journaled file system"

B: fsck interactive repair. Journaling file systems (HFS+) avoids the need to run fsck - OS X Journaling is on by default in OS X

How is A resolved against B?

R C-R wrote:

~There is no way to be certain but it appears this specific problem..

~I have a lot of questions, essentially no answers..

~I'm also not quite sure what you think..

~I do not understand why you concluded that..

~It is still not clear to me exactly why or how you think..

~Again, I'm not sure what you mean by this…

I dont know if you are doing so by accident or design, but the quotes from 6 different posts by yourself above are classical Greek Sophistry, and is unhelpful as per problem solving.    I have a "lot of questions" as well, and attempting to help by testing a logical theory

Its premise is to:  Albinus: "dissuade others from postulating logical theory and conclusions and testing same for resolving questions".

To say that by implication "nobody can/should say anything without 100% proof" (in cases of Sophistry by definition, nobody ever can achieve 100% proof since the barrier is always 'moved back') is not helpful.

By definition, even to test a theory that proves to be wrong is still logically "helpful", ...as Thomas Edison said he didn't "make 1000s mistakes in theory testing, but found 1000s of ways NOT to make a light bulb"

Do you have a logical theory others may test that fits the observed results?          That would be helpful.

1. The first form of fsck_hfs quickly checks the specified file systems to determine whether they were cleanly unmounted.      

2. The second form of fsck_hfs preens the specified file systems.  It is normally started by fsck(8) during systen boot, when a HFS file system is detected.  When preening file systems, fsck_hfs will fix common inconsistencies for file systems that were not unmounted cleanly.  If more serious problems are found, fsck_hfs does not try to fix them, indicates that it was not successful, and exits.      

3. The third form of fsck_hfs checks the specified file systems and tries to repair all detected inconsistencies.

4. If no options are specified fsck.hfs will always check and attempt to "fix" the specified file systems.

http://www.mactipsandtricks.com/articles/ORmm_appb2.lasso

POWER USERS' CLINIC Journaling vs. fsck

Mac OS X 10.4 comes with journaling turned on. As noted on Section A.4, journaling means that the Mac keeps a diary about every tiny bit of hard drive activity. In event of a crash or freeze, the Mac knows precisely what was going on at the time, and precisely which files might have been damaged.

In theory, then, you'll never need fsck at all. After all, there's nothing to check. The Mac's journaling software is always on top of things—and, if the journal indicates that there was trouble saving a file, Mac OS X can finish or undo the change.

Even Apple concedes, however, that in the real world, things can still go wrong, even with journaling turned on.

Apple:

http://support.apple.com/kb/ts2028

If you do run fsck, it is best if you use -n and -f flags so that it will not actually modify the volume.

    Because running fsck to repair a file system which is mounted for read/write operations can potentially cause severe data corruption or loss, the file system is normally checked while unmounted, mounted read-only, or with the system in a special maintenance mode that limits the risk of such damage

Clarification on developers indications below would be helpful

*It's well-known that you should never fsck a mounted partition. I can understand how this could easily lead to corruption if the filesystem is written to by fsck

      *When running the fsck command, you should always unmount the filesystem first. This will reduce the chances of any corruption occurring.

*Also take care not to fsck a mounted file system, even root, as you may do more damage to the file system than you intended to correct. Fsck'ing a clean file system does nothing for you other than give you peace of mind. Usually inconsistencies are created when the system is not properly shutdown, such as a power failure or reset. The OS X man pages on fsck are unclear as to whether fsck supports hfs+ file systems.

I am merely presenting a logical theory that others with verified data loss / repartitioning can look for as a point of clarification.

If some other users could check error logs for any fsck , even proving said theory wrong would be helpful.

Elimination diagnosis is as helpful in deduction as is direct analysis, especially if the theory is sound.

Additionally, testing the newly released WD software will shed light on things.

As already stated:

This is only logical theory at present

Peace

Have you got anything mentioning that disk before 09:51 in the logs. I wonder if there is any indication why the fsck was required?

Look in /var/log/diskarbitrationd.log - that manages the mounting & disk detection. (Also try man diskarbitrationd)

I can't see how to put diskarbitrationd in debug mode, the launchd plist looks different to other nix tools, there is no program args to insert the -d flag. I guess you cram it into the program string?

I thought the journal was being truncated & then the fsck took place, however those times indicate it is the other way around.

I would look into how the journal is stored, those addresses look like disk or DB addresses. It appears to be resetting the journal back to nothing?

I'd consider testing PlotinusVeritas single user mode fsck, but I'm not entirely sure I follow why it would be different that the fsck that is run within a normal boot.

Does PlotinusVeritas have a non verbose mode? It's tough trying to follow you PV

Drew Reece wrote:

 

Have you got anything mentioning that disk before 09:51 in the logs. I wonder if there is any indication why the fsck was required?

 

Look in /var/log/diskarbitrationd.log - that manages the mounting & disk detection. (Also try man diskarbitrationd)

....

I can't find a diskarbitrationd.log or any file that begins with diskarb (except the unix command file).

One of the more difficult things about forcing the Seagate 3T to have trouble mounting is that I really don't know exactly what causes fsck to launch.

My testing procedure is to mount the drive, copy 3-4GB of data to it (typically a iPhoto library) and then rearrange the icons in the root level of the drive and eject it via the Finder or unmount it via Disk Utility. I then try to re-mount it via Disk Utility or by unplugging and replugging the FW800 interface. Recently I've been monitoring the system and fsck_hfs logs while I do this complicated procedure to see if I can figure out which of these actions actually cause fsck to run on mount -- to no avail.

This AM after one pass of the procedure  the Seagate 3T mounted beautifully twice. So I decided to unplug the drive's power supply to force the interface to reboot. This is not part of my normal procedure but I was getting bored

After plugging in the power supply, I plugged the FW800 cable into the MBP and bingo the drive did not mount. That is when I tested my theory that other processes could try to access the unmounted drive while fsck was still running. 8 minutes is a long time. The bonus was learning that Disk Utility would not only try to "repair" the drive, but that after it failed it would also give very bad advice as to what to do next.

I've gleaned the sys log for problems at the time of unmounting the drive and see nothing more than I have posted. Certainly nothing directly referencing Seagate 3T or disk1s3.

-- GetRealBro

I just mounted and unmounted the Seagate 3T three times. All three were quick and successful. I don’t know why I hadn’t noticed this before but fsck was called EVERYTIME the disk is mounted.

System.log…

Nov 27 13:06:49 GetRealBros-MacBook-Pro kernel[0]: hfs: mounted Seagate 3T on device disk1s3

Nov 27 13:07:09 GetRealBros-MacBook-Pro.local fseventsd[50]: Events arrived for /Volumes/Seagate 3T after an unmount request! Re-initializing.

Nov 27 13:07:09 GetRealBros-MacBook-Pro.local fseventsd[50]: creating a dls for /Volumes/Seagate 3T but it already has one...

Nov 27 13:07:09 GetRealBros-MacBook-Pro kernel[0]: hfs: unmount initiated on Seagate 3T on device disk1s3

Nov 27 13:07:09 GetRealBros-MacBook-Pro.local fseventsd[50]: disk logger: failed to open output file /Volumes/Seagate 3T/.fseventsd/fbd8c30529ce670d (No such file or directory). mount point /Volumes/Seagate 3T/.fseventsd

Nov 27 13:07:40 --- last message repeated 1 time ---

Nov 27 13:07:48 GetRealBros-MacBook-Pro kernel[0]: hfs: mounted Seagate 3T on device disk1s3

Nov 27 13:08:52 GetRealBros-MacBook-Pro kernel[0]: hfs: unmount initiated on Seagate 3T on device disk1s3

Nov 27 13:09:17 GetRealBros-MacBook-Pro kernel[0]: hfs: mounted Seagate 3T on device disk1s3

And the corresponding fsck_hfs.log entires….

/dev/rdisk1s3: fsck_hfs started at Wed Nov 27 13:06:49 2013

/dev/rdisk1s3: /dev/rdisk1s3: ** /dev/rdisk1s3 (NO WRITE)

/dev/rdisk1s3:    Executing fsck_hfs (version hfs-226.1.1).

QUICKCHECK ONLY; FILESYSTEM CLEAN

/dev/rdisk1s3: fsck_hfs completed at Wed Nov 27 13:06:49 2013

/dev/rdisk1s3: fsck_hfs started at Wed Nov 27 13:07:48 2013

/dev/rdisk1s3: /dev/rdisk1s3: ** /dev/rdisk1s3 (NO WRITE)

/dev/rdisk1s3:    Executing fsck_hfs (version hfs-226.1.1).

QUICKCHECK ONLY; FILESYSTEM CLEAN

/dev/rdisk1s3: fsck_hfs completed at Wed Nov 27 13:07:48 2013

/dev/rdisk1s3: fsck_hfs started at Wed Nov 27 13:09:17 2013

/dev/rdisk1s3: /dev/rdisk1s3: ** /dev/rdisk1s3 (NO WRITE)

/dev/rdisk1s3:    Executing fsck_hfs (version hfs-226.1.1).

QUICKCHECK ONLY; FILESYSTEM CLEAN

/dev/rdisk1s3: fsck_hfs completed at Wed Nov 27 13:09:17 2013

-- GetRealBro

GetRealBro wrote:

 

I just mounted and unmounted the Seagate 3T three times. All three were quick and successful. I don’t know why I hadn’t noticed this before but fsck was called EVERYTIME the disk is mounted.

....

Nerver mind  I just checked the fsck_hfs.log on my 10.6.8 partition which goes back to April of 2011. An fsck QUICKCHECK on every disk/partition mounted has been standard behavior at least since then.

The anomalies are the longer fsck runs which start to show up when I was using 10.6.8 to mount/verify/repair partitions that would not mount in Mavericks.

A little background....This Seagate 3T drive was the Time Machine drive for my MBP.  My practice over the last few years was to turn off TM and leave the drive unmounted until I wanted a backup (roughly once a week). Then I would mount this drive, click Backup Now in TM and when it was finished I'd unmount the drive. I also used the drive for archives of iPhoto Libraries etc.. So while running 10.6.8, this drive had been mounted and unmounted lots of times since April of 2011 without any problems as indicated in the fsck_hfs.log

So my questions now are...

What causes the system to do these longer fsck runs when mounting some drives, some of the time?

And why did it only start happening after the drives were used in Mavericks?

--GetRealBro

GetRealBro 

What causes the system to do these longer fsck runs when mounting some drives, some of the time?

And why did it only start happening after the drives were used in Mavericks?

So at least one lowish level disk utility can attempt to interrupt a “fsck on mount” while it is still running.

      -likely:

Mavericks: Spotlight Indexing Forever!

"Spotlight was constantly estimating the time to Index one of my external drives" 

(reported solved when: drive put under Privacy tab exclusion list under Spotlight Preferences)

"For me, its the Spotlight Indexing service and my external RAID array. Once I excluded the RAID, my Memory utilization dropped from 98% to 7%"

       -User A.K.A. reported same as yourself on fsck on TM external:

https://discussions.apple.com/message/23917080#23917080

"ran the file-system check process (i.e. fsck_hfs process under Activity Monitor...It ran the process for about 10 to 15 minutes"

     -Those with corruption, have they reported seeing in error logs:

If fsck found issues and has altered, repaired, or fixed anything, it will display this message:

FILE SYSTEM WAS MODIFIED

(?)

PlotinusVeritas wrote:

I have not postulated a "vague" theory, rather a  logical one based upon the limited given evidence.

You haven't postulated any theory at all, just a torrent of words that reduces to "here's some stuff that may or may not be relevant, but I have no idea if or how it is."