Anupam Aggarwal writes:
>>Anyway, fsck would be main way. And on other hand, if we want to add
>>mitigation for corruption, we would have to see much more details of
>>this corruption. Can you put somewhere to access the corrupted image
>>(need the only metadata) to reproduce?
>
> Sorry, uploadi
Hi Ogawa,
>Anyway, fsck would be main way. And on other hand, if we want to add
>mitigation for corruption, we would have to see much more details of
>this corruption. Can you put somewhere to access the corrupted image
>(need the only metadata) to reproduce?
Sorry, uploading of any file not all
Anupam Aggarwal writes:
>>So what was the root cause of slowness on big directory?
>
> Problem happened on FAT32 formatted 32GB USB 3.0 pendrive, which has
> 20GB of data, cluster size is 16KB It has one corrupted directory
> whose size calculated by fat_calc_dir_size() is 1146896384 bytes
> i.e.
Hi Ogawa,
>So what was the root cause of slowness on big directory?
Problem happened on FAT32 formatted 32GB USB 3.0 pendrive, which has 20GB of
data, cluster size is 16KB
It has one corrupted directory whose size calculated by fat_calc_dir_size() is
1146896384 bytes i.e. 1.06 GB.
When directo
> There are many implementation that doesn't follow the spec strictly. And
> when I tested in past, Windows also allowed to read the directory beyond
> that limit. I can't recall though if there is in real case or just test
> case though.
>>> Thanks Ogawa, yes there are many implementations, pref
AMIT SAHRAWAT writes:
> There are many implementation that doesn't follow the spec strictly. And
> when I tested in past, Windows also allowed to read the directory beyond
> that limit. I can't recall though if there is in real case or just test
> case though.
>>> Thanks Ogawa, yes there are many
e are no such error reported on our side.
We had to trace to check the point of stuck in simple 'ls -lR'.
Thanks & Regards,
Amit Sahrawat
- Original Message -
Sender : OGAWA Hirofumi
Date : 2020-06-30 16:38 (GMT+5:30)
Title : Re: [PATCH] fs: fat: add check
Anupam Aggarwal writes:
> Max directory size of FAT filesystem is FAT_MAX_DIR_SIZE(2097152 bytes)
> It is possible that, due to corruption, directory size calculated in
> fat_calc_dir_size() can be greater than FAT_MAX_DIR_SIZE, i.e.
> can be in GBs, hence directory traversal can take long time.
Max directory size of FAT filesystem is FAT_MAX_DIR_SIZE(2097152 bytes)
It is possible that, due to corruption, directory size calculated in
fat_calc_dir_size() can be greater than FAT_MAX_DIR_SIZE, i.e.
can be in GBs, hence directory traversal can take long time.
for example when command "ls -lR"
9 matches
Mail list logo
