So I was trying to index Total Size On Disk on a seemingly broken SSD and I thought because a few others have had no issues that there is an issue with that SSD.
But now I do the same also with NTFS indexing on a different device, HDD, and it seems to be entirely stuck.
It has managed to do 13 million folders, but 60,000 it is just stuck trying to do.
At least with this device, it is doing new folders or modified folders, while the SSD one is just broken and I think it refused to.
Why is Total Size On Disk the one breaking it and is there a way to still get it?
A differently named WPS version?
A way to pause it for any folder currently struggling with it while allowing it to continue indexing new or modified folders?
A way to find out what files/folders may be causing it to break? I think just like the SSD, if I restart the db it will successfully index some of the 60,000 folders..If that is the case, restarting a bunch will narrow down which folders are causing it but that's a lot of narrowing down manually and it can break quickly after launching and it does not restart quickly given its 53 or so million files indexed.
I could keep the current db on as it still does most folders, problem is it scans everything constantly.
The device is clearly not happy about it and it lags the device, if I do tasks I've done before it might freeze and going to This PC will result it in looking like it's offline because EBV is basically using all resources on it and I have to wait at that point.
It mostly doesn't reach the state of freezing like that, but it is a sign that it's being heavily used.
I mention NTFS because I am not sure it's necessarily the properties itself and maybe NTFS and properties as a db with folder monitor for some of the folders it maybe is failing on has worked just fine.
Maybe that's just that something breaks before it reaches those folders and if I restart it enough times it'll eventually get to those folders like it has on the folder monitoring version
Or it's that I had been indexing the same properties from the start of those folders while with the NTFS version I am scanning the whole device I am indexing on and it's old and already has 50+ million files on it to index.
I doubt a whole new index will fix this issue and instead lead to it reading the device a bunch more and still ending on folders that cause problems just like on the SSD where it was small enough that I did try a whole new index by removing the old db and it eventually reached the same problem.
Maybe debug logging could help shed a light on what exactly is causing the issue but it does seem to get stuck on stuff, at least on the SSD, that it later got through indexing after restarts. So not sure knowing what it gets stuck on helps know what it permanently would get stuck on. (And it would probably require thousands of restarts to get to the more permanently stuck files/folders if we look at how few files and folders managed to be indexed eventually by restarts on the SSD db below)
Here are states I noted after restarts for the SSD before I gave up and excluded total size on disk entirely because not even excluding the last few folders fixed the issue, not even excluding all folders fixed it. Only removing the property completely did.
Both totals is which had no total size on disk, each new folder was a restart where it managed to index more, or not.
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\78 files, 193 folders"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\75 files, 191 folders"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\56 files, 179 folders"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\48 files, 171 folders"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\37 files, 166 folders"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\32 files, 166 folders again"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\27 files, 162 folders"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\24 files, 162 folders again"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\24 files again, 162 folders again"
Maybe it's my system or my storage devices..Or maybe it can replicated on any device that already has a million or more files and folders on it?
I don't know if you could test this on a storage device yourself and get the same result, maybe it has to be broken in some way.
I think the SSD is broken in some way or it's the SATA port that rarely, every few months, causes it to suddenly act like the device is offline.
I now run the SSD externally, so restarting it is as easy as switching off the housing and on, unlike SATA where I have to restart the whole machine for that one device to work again. Time will tell if it fails to be kept on the entire time without an inaccessible error eventually.
Either way the HDD definitely has to be broken in some way, it's 8 years old and has been read I believe hundreds of millions of times.
I only still use it because I've had worse experiences with newer supposedly sturdier devices that fail after some months, server-type HDDs I guess..EXOS.
Some HDDs are built different I suppose.
But now I do the same also with NTFS indexing on a different device, HDD, and it seems to be entirely stuck.
It has managed to do 13 million folders, but 60,000 it is just stuck trying to do.
At least with this device, it is doing new folders or modified folders, while the SSD one is just broken and I think it refused to.
Why is Total Size On Disk the one breaking it and is there a way to still get it?
A differently named WPS version?
A way to pause it for any folder currently struggling with it while allowing it to continue indexing new or modified folders?
A way to find out what files/folders may be causing it to break? I think just like the SSD, if I restart the db it will successfully index some of the 60,000 folders..If that is the case, restarting a bunch will narrow down which folders are causing it but that's a lot of narrowing down manually and it can break quickly after launching and it does not restart quickly given its 53 or so million files indexed.
I could keep the current db on as it still does most folders, problem is it scans everything constantly.
The device is clearly not happy about it and it lags the device, if I do tasks I've done before it might freeze and going to This PC will result it in looking like it's offline because EBV is basically using all resources on it and I have to wait at that point.
It mostly doesn't reach the state of freezing like that, but it is a sign that it's being heavily used.
I mention NTFS because I am not sure it's necessarily the properties itself and maybe NTFS and properties as a db with folder monitor for some of the folders it maybe is failing on has worked just fine.
Maybe that's just that something breaks before it reaches those folders and if I restart it enough times it'll eventually get to those folders like it has on the folder monitoring version
Or it's that I had been indexing the same properties from the start of those folders while with the NTFS version I am scanning the whole device I am indexing on and it's old and already has 50+ million files on it to index.
I doubt a whole new index will fix this issue and instead lead to it reading the device a bunch more and still ending on folders that cause problems just like on the SSD where it was small enough that I did try a whole new index by removing the old db and it eventually reached the same problem.
Maybe debug logging could help shed a light on what exactly is causing the issue but it does seem to get stuck on stuff, at least on the SSD, that it later got through indexing after restarts. So not sure knowing what it gets stuck on helps know what it permanently would get stuck on. (And it would probably require thousands of restarts to get to the more permanently stuck files/folders if we look at how few files and folders managed to be indexed eventually by restarts on the SSD db below)
Here are states I noted after restarts for the SSD before I gave up and excluded total size on disk entirely because not even excluding the last few folders fixed the issue, not even excluding all folders fixed it. Only removing the property completely did.
Both totals is which had no total size on disk, each new folder was a restart where it managed to index more, or not.
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\78 files, 193 folders"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\75 files, 191 folders"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\56 files, 179 folders"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\48 files, 171 folders"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\37 files, 166 folders"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\32 files, 166 folders again"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\27 files, 162 folders"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\24 files, 162 folders again"
"C:\64-Portable\Everything v1.5.0.1383a x64\A2 MX500 SSD1\24 files again, 162 folders again"
Maybe it's my system or my storage devices..Or maybe it can replicated on any device that already has a million or more files and folders on it?
I don't know if you could test this on a storage device yourself and get the same result, maybe it has to be broken in some way.
I think the SSD is broken in some way or it's the SATA port that rarely, every few months, causes it to suddenly act like the device is offline.
I now run the SSD externally, so restarting it is as easy as switching off the housing and on, unlike SATA where I have to restart the whole machine for that one device to work again. Time will tell if it fails to be kept on the entire time without an inaccessible error eventually.
Either way the HDD definitely has to be broken in some way, it's 8 years old and has been read I believe hundreds of millions of times.
I only still use it because I've had worse experiences with newer supposedly sturdier devices that fail after some months, server-type HDDs I guess..EXOS.
Some HDDs are built different I suppose.
Statistics: Posted by Herkules97 — Sun Oct 06, 2024 8:44 pm