[BUG] v1.4.0.709b(x64) freezes while scanning ReFS on W10x64

[V@no]

Hello.

Setup:
Windows 10 pro x64
Storage Spaces -> 2 HDDs in Two-way mirror -> single partition formatted in ReFS (D:\ drive)
Everything v1.4.0.709b (x64) run as administrator.

Issue:
On start it freezes during scanning ReFS volume (D:\ drive), debug shows infinite repeat of

Code: Select all

WAT
invalid page access at offset 32852 len 2

Database never created.

Thank you.

P.S.
dump file available 323mb (50mb compressed)

[void]

Thanks for the bug report.

I am looking into the issue.

Could you please email me the first 50,000 lines of the verbose debug output.

The verbose option will display a lot more ReFS indexing debug information:
Please make sure Everything is not running.
From a command prompt, run:
Everything.exe -debug -verbose > out.txt
Force a rebuild from Tools -> Options -> Indexes.

Thanks for the dump file offer, however, the dump file is not required at this stage.
I can see Everything is trying to continuously parse a zero lengthed ReFS attribute, this is a bug and will be fixed for the next update.

Thanks for your support.

[void]

This issue should be fixed in Everything 1.4.0.713b

[V@no]

Thank you.
It is working fine. Just need to be patient on first start while it create the database. On my drive with over 2m files and 200k folders it takes about 20-25 minutes for it to complete the initial scan (also the window can freeze while it's scanning, which is "normal"), but once database created it starts instantly.

I hope the scan performance will be improved in the future, but it would be nice to have any kind of indication that the program is still alive while it's scanning, perhaps spinning "\" like in old dos programs or moving dots...?


One more question, my understanding is that Everything doesn't scan drives on startup when database is present, what happens when new files added (or deleted) before Everything started will it be shown in the results?

Thanks again.

[void]

I hope the scan performance will be improved in the future, but it would be nice to have any kind of indication that the program is still alive while it's scanning, perhaps spinning "\" like in old dos programs or moving dots...?

The poor ReFS indexing performance is due to the low random 4k read performance of hard disk drives.
I'm working on improving the ReFS indexing performance at the cost of RAM by reading in entire sections of the ReFS file table sequentially.

I'll look at adding ... or \|/- to the status bar to show Everything is still alive.

One more question, my understanding is that Everything doesn't scan drives on startup when database is present, what happens when new files added (or deleted) before Everything started will it be shown in the results?

The initial full scan should only occur once.
Everything will keep its ReFS index up to via the ReFS volumes USN Change Journal.
The USN Change Journal is a log of all changes made to the ReFS volume.
This journal is managed by the ReFS driver, so Everything does not need to be running.
Typically this journal will store changes for about a week, varying on your file system usage.

Thanks for your support.

[V@no]

The poor ReFS indexing performance is due to the low random 4k read performance of hard disk drives.
I'm working on improving the ReFS indexing performance at the cost of RAM by reading in entire sections of the ReFS file table sequentially.

Just curious why doesn't NTFS suffer from this?

[void]

Just curious why doesn't NTFS suffer from this?

NTFS has a Master File Table (MFT) that is stored compactly in one location (sometimes more than one if the MFT is fragmented, which is rare).
It's very fast to sequentially read the entire thing.

ReFS does not have a master file table.
Files and directories are stored in 16k directory pages spread out all over the place.