Dear all,

I wonder whether you could help with a query:--

I have a flash drive of 64 GB with a bunch of corrupt files on it (all in a single directory). I asked fsck to scan the drive and it offered to fix this directory, noticing that it is corrupt. How long should it take?

The size of the corrupt directory is confusing -- file manager claims that it is around 50 GB (which is probably nonsense because, with the other data, that would exceed the capacity of the flash drive. File manager, for 'Properties' shows the memory-usage pie chart shows that I would expect prior to corruption, a bunch of data with a little space (around 53 GB), but claims that the drive contains 103.1 GB in total (on a 64 GB drive!).

So basically, fsck is scanning what claims to be 50 GB of data (but was around 2 GB before it corruped). It's been working for around 8 hours, you could fry an egg on my laptop's heat-sink and fsck is running on around 99% CPU.

I'm using a Thinkpad X60 (32-bit, Fedora 20), 3GB RAM and a 2.00GHz × 2 Intel processor.

So, any ideas on how much longer it will take?

Thanks for the help,

Oliver

Attached Thumbnails

 

Hi there,

that's very hard to tell. It depends very much on the number of files - and hey, about 170'000 files is an awful lot!
Your screenshot reports "msdos" as the file system being used; on Linux's behalf, that's a generic term including all FAT variants (i.e. FAT12, FAT16 and FAT32). A Windows file system anyway. So I would prefer to have it checked and repaired by a native Windows machine, or at least by a real Windows in a VM.

Actually, I've never run a Linux fsck on a FAT file system, but I know that fsck takes ages even for a routine check of an ext3 volume. Whenever my computer decides to run a routine check on the 400GB data partition (which is about 3/4 full), that takes about 20..30 minutes. And that is without errors to be fixed!

That's a very clear indication that something's going wrong. Usually, fsck spends a lot of time waiting for the HDD (or for whatever storage medium you're using). A CPU load near 100% means that fsck is hardly accessing the storage device any more, but is rather locked up in some sort of infinite loop chewing on data cached in RAM. Maybe the FAT indicates a cluster chain that forms a loop, and fsck is checking this loop over and over again? Weird things can happen ...

Forever, is my guess. Unless you stop it.

[X] Doc CPU

Thanks for the info! As you say, something appears to be wrong, perhaps it's something to do with the fact that my system can't decide how much data there is? Some kind of recursion?

As such, you wouldn't happen to know another way of deleting a whole directory of corrupt files? Every time I try to do so, the whole drive goes read-only -- can't change permissions, can't rm -f.

Thanks,

Oliver

Hi there,

the mismatch between total capacity, available space and the cumulated size of all files is a clear indication for something wrong. What it really is and how it happened - no idea.

On a FAT file system, there are two ways to determine the amount of space allocated:
a) scan the FAT and count all non-free blocks
b) scan all directories and recursively sum up file sizes
When you query the media's properties, the FAT driver typically uses the first method because it's fast and produces accurate results. When you query the properties of a directory in your file manager, it uses the second method because it's versatile and can also be applied to individual directories, while a) always considers the entire volume. Usually, the amount of allocated space computed that way is less than what method a) indicates. That's because the space is always given or taken as entire blocks (clusters), which are typically 4kB with FAT, regardless of the actual file size. So even a small text file of 182 bytes is occupying 4kB of the volume's space.

In your scenario, however, it's the other way round: The accumulated file size is bigger than the total space used on the volume, it's even bigger than the total capacity. Clearly wrong.

Could be. Or multiple records in a directory referencing the same cluster chain. In Unix file systems this feature is known as "hardlinking" a file. But in FAT it's not officially supported and thus considered an error. There are no tools to create such a structure deliberately, and usually FAT drivers can't deal properly with it.

I'm afraid no. As I said, I'd recommend to run a file system check on a Windows PC. My experience is that Windows's chkdsk (or scandisk) can deal with these problems fairly well. It'll try to recover logical errors, e.g. make cross-linked files into two separate files. Of course, there's a certain risk that some of the files are already shaken up or truncated in a way that can't be recovered.

Tell you what I would do: Copy the entire contents from the bad volume to another. Maybe some files can't be copied any more because their structure is damaged. But the duplicate of those that can will be fully accessible again.
Then re-format the FAT volume.

[X] Doc CPU

I've checked and fortunately, as the drive was a backup, I haven't actually lost any unique data. As such, I've re-formatted it and started the backup again. Thanks for all the help and guidance! First linux problem that I couldn't fix, you know? Either on my own or with the help of forums -- though I guess its party a MSDOS problem!

Thanks again,

Oliver