Re: Corrupted file names

Thanks Greg (and also to Dale for his subsequent posting on perceived 
Linux failings concerning NTFS management).

There are zillions of test tools available, and I really don't know 
where to start. My hunch is that the corruption is occurring only on my 
five-year old internal Asus SSD and not on the new external Samsung SSD. 
A quick search on the web shows that users seem to be more worried about 
performance indicators than about occasional corruption. I propose to 
try to find expert advice on whether tweaking any of the FSTAB 
parameters could help to stabilize the system, and also to start a 
rigorous log to try to understand the problem better. The other options 
like an all-Linux or all-Windows system are not very appealing for the 
moment.

Best regards,

     John

Le 07/03/2024 à 19:40, Greg Troxel a écrit :
> John Rose <[email protected]> writes:
>
>> So I went into Windows and ran chkdisk and found that there was indeed
>> and index problem with the above file. Once fixed everything syncs
>> OK. I am not sure whether this file corruption problem happened at the
>> same time as the similar ones reported on 20 February or later.
> Thanks for continuing to look into this and figure out more about what
> happened.
>
> It is basically a 100% conclusion that user programs cannot cause file
> system inconsistencies.
>
>> Quite disturbing and annoying, still no clear idea about why it
>> happened and what to do? Even if there is no direct incrimination of
>> unison, perhaps it is possible that the high volume IO is enough to
>> push the Ubuntu management of ntfs beyond its limit? I will post
>> further news if the problem continues.
>
> I think it is plausible that high-volume IO is troublesome while low
> loads are not.  Any simllar sync program will neessarily call stat(2) on
> efery file, and when actually syncing will read and write a lot.
>
> My only thought (other than "Don't use windows at all." :-) is that
> there must be filesystem exerciser/tester programs that do a large
> number of operations, from multiple threads, and check the results.
> You might find and run such a tool.
>
> Greg

-- 
************

                John B. Rose
                1 Bis rue des Châtre-Sacs
                92310 Sèvres, France

                Email: [email protected]

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].