If this monolithian db feels like re-scanning a device, what will need to be re-scanned?
Will all devices need to be re-scanned, will only the extra properties like Size on Disk be re-scanned on those devices, only the device that is "out-of-date", only a few files on that device or does it just mean it flushes index journal and re-sorts filenames?
TL;DR2:Also..Is there a limit with NTFS monitoring that can cause index journal to lag behind? I am not sure, but it seems like the index journal for the monolithian one grabs less than the individual dbs total..
I have done no experiments.
NTL;DR:
So I have a monolithian db finally..have had for 2 months so it's not that finally.
I have been keeping the database lighter because I still run all my singular-device dbs like if I have A:\, I have Monolith that monitors it and also let's say A2 that only monitors A:\.
To clarify, monolith can have A:\, B:\, C:\ and so on.
Device db will only have A:\.
Only B:\.
Or so on.
I have been thinking of getting rid of at least all folder monitors since the monolithian one can be used for exporting filelists for stuff across multiple devices, also for archiving with 7-Zip. And the folder ones are primarily for that besides the phone and USB-stick ones.
And then adding the 4 extra properties I use, like Size on Disk, to the monolithian one and removing them on the singular ones.
One issue I've had in the past is when EBV decides that a device is out-of-date and re-scans. I don't want to re-scan entire devices and I don't know why it happens.
I don't remember it well enough to know what actually changes either.
HERE IS QUESTION
If this monolithian db feels like re-scanning a device, what will need to be re-scanned?
Will all devices need to be re-scanned, will only the extra properties like Size on Disk be re-scanned on those devices, only the device that is "out-of-date", only a few files on that device or does it just mean it flushes index journal and re-sorts filenames?
Also..Is there a limit with NTFS monitoring that can cause index journal to lag behind? I am not sure, but it seems like the index journal for the monolithian one grabs less than the individual dbs total..
I have done no experiments, so I am not sure if it's just because I purge at different times and then just ignore that when comparing.
I forgot to turn off pagefile after system reset or at least keep it small for the supposed benefit of BSOD dumps, it's at 50GB and seems to hold a good chunk of the monolith one. Don't know how exactly it works, so not sure if it can over time, as it unloads to disk, cause index journal to slow down.
No db seems to have even 50% loaded in working set, so I doubt that can cause it. Maybe it's just me not doing proper comparisons and monolith has as much..I looked at a journal entry for ONE file between monolith and single-device db and it has the same metadata so at least for that file it's not missing on either
I didn't buy more RAM not to use it, but I am still running about 70% commit charge again and monolith is only monitoring maybe 20% of my devices so I will at least need to choose only one type that has extra properties if I want to add currently unplugged devices to it in the future. Will still run individual dbs because of index journal overflowing, maybe that can be remedied if EBV supports more than 4GB in the future.
Original title:Monolithian db, curious about times when EBV decides a file is out-of-date