restoring_a_yun

Hi,

After playing a lot with the Yun, discovering that in many cases, the SD Card don't work, that the file system corrupt the fat when you put too much files and the SD Card, and so on... I decided to restore the Yun, using this way of doing:

http://playground.arduino.cc/Hardware/Yun#restoring_a_yun

At the end of the process, while typing ./reset-to-factory-anyway, the blue light of the Yun started to flash, and.... flash, flash, flash, and never stopped. After one hour, I decided to unplug, plug the Yun again and... see nothing has change...

Any idea?

Best regards
PL

Edit: I tried also this "To reset the OpenWrt-Yun distribution to its default state, press the WiFi reset button for at least 30 seconds. The board reverts to the original settings: like just taken out of the box or to the latest update of the OpenWRT image you have reflashed before. Among other things, this removes all installed files and network settings. "
But it don't work. Even if the YUN is back in the Wifi menu of the computer, all files are stil there, and the password stay the same...

Try to follow this guide http://arduino.cc/en/Tutorial/YunSysupgrade

ansb:
the SD Card don't work, that the file system corrupt the fat when you put too much files and the SD Card

This caught my eye... There is a common issue out there with "fake" SD cards that have supposedly been "upgraded" to a higher capacity. This is where an unscrupulous vendor re-writes the indicated capacity of a card, to where it says there is more memory than is really there. For example, they may take a 4GB card, and change the information on it to make it look like a 16 GB card. Everything works well as files are added, up until you reach the actual capacity (4 GB in this example.) At that point, you get file corruption and data loss. Using name brand cards like SanDisk is no assurance, since an unscrupulous vendor who will fake the card capacity will also often fake the manufacturer's logos.

Before you go too far blaming the Yun, put the card in another computer and try filling it up with files. Or do a search for fake a SD card test utility. You could find out that the issue is with your SD card, not the Yun.

Angelo9999:
Try to follow this guide http://arduino.cc/en/Tutorial/YunSysupgrade

Don't work

I've tried this before without any success :frowning:

ShapeShifter:
This caught my eye... There is a common issue out there with "fake" SD cards that have supposedly been "upgraded" to a higher capacity. This is where an unscrupulous vendor re-writes the indicated capacity of a card, to where it says there is more memory than is really there. For example, they may take a 4GB card, and change the information on it to make it look like a 16 GB card. Everything works well as files are added, up until you reach the actual capacity (4 GB in this example.) At that point, you get file corruption and data loss. Using name brand cards like SanDisk is no assurance, since an unscrupulous vendor who will fake the card capacity will also often fake the manufacturer's logos.

Before you go too far blaming the Yun, put the card in another computer and try filling it up with files. Or do a search for fake a SD card test utility. You could find out that the issue is with your SD card, not the Yun.

This is not the case. I can fill 32Gb on this card without any problem.
In fact this kind of problem is an old one. When I started to play with computer (1985), we had floppies and them, small HD. The FAT of the floppy and of the HD where big enought for a small number of small files, but not a "large quantity".
So, when you were putting a lot of small files, before the disk was full, the FAT was. At this moment, the system was unable to retrieve the files: they had their name corrupted (eg TEST.TXT became tyuuy.getf.poouk) and also size of files (files with eg a size of 565654889To and so on).
This is exactly what happened on the SD. When you just put a few files, everything is OK. But after saving about 6.000 files, the system started to corrupt them. And as I've to save tiles from OpenStreetMap, I've to save more than 6.000 small files. I tried to format the card, save the files directly from the computer, save them using a FTP tool on the Arduino... No change.
I notice also than I've an SD Card which, when used on the Arduino, seem to be the drive sda1 but in fact, is not. And when I save on this SD, data are saved on the internal memory of the Arduino. Not sure the disk driver is really perfect...

I'll continue and give you the result.

Thank for your help

ansb:
This is not the case. I can fill 32Gb on this card without any problem.

Good news, that's one potential problem that's not an issue in this case.

In fact this kind of problem is an old one. When I started to play with computer (1985), we had floppies and them, small HD. The FAT of the floppy and of the HD where big enought for a small number of small files, but not a "large quantity".

You might be confusing the FAT filling up with the root directory filling up. In the very old FAT file systems, besides the FAT, there was a fixed size root directory, and no way to create subdirectories. So there was an absolute limit to the number of files that could be stored on a disk. Make the files small enough and you could run out of directory entries before you ran out of disk space or FAT space. (But you should get a file creation error at this point, not corruption of existing files.)

So, when you were putting a lot of small files, before the disk was full, the FAT was. At this moment, the system was unable to retrieve the files: they had their name corrupted (eg TEST.TXT became tyuuy.getf.poouk) and also size of files (files with eg a size of 565654889To and so on).

There is no way the FAT can fill up before the disk -- there is a one-to-one correlation between FAT entries and clusters on the disk. If the FAT is full, the disk is considered full, and will report that there is zero space left. Now, that being said, since a cluster as recorded by the FAT is usually more than one sector as stored on the disk, odds are that not every sector in a cluster will actually be used. (On average, for a collection of randomly sized files, half of the sectors in the last cluster will not actually be used.) While the actual size of the data on the disk is usually less than the amount of space allocated for the file on the disk, resulting in some wasted space, that space is not reported as available. Therefore, there should never be a situation where there is still free space reported on a disk but the FAT is full. (In essence, the free space is defined as the number of unallocated FAT entries.)

If you're getting corrupted file names and lengths, and running into a corrupted FAT that isn't properly reflecting the data on the disk, then you indeed do have problems with your disk. But in the almost 40 years I've been using computers (since before MS-DOS existed) I've never heard of this corruption happening because too many small files were written to the disk. I've certainly experienced disk corruption and data loss, but not as a result of too many small files. I suspect your corruption has other causes.

This is exactly what happened on the SD. When you just put a few files, everything is OK. But after saving about 6.000 files, the system started to corrupt them.

Are all of these files going in the root directory, or in a sub directory? If you are putting them in the root, try putting them in a sub directory. There can be a difference. I've put over 5,000 files on a 32 GB SD card and over 10,000 files on a 64 GB USB stick (both running FAT file system) and I've never had this kind of file corruption.

I notice also than I've an SD Card which, when used on the Arduino, seem to be the drive sda1 but in fact, is not. And when I save on this SD, data are saved on the internal memory of the Arduino.

Yes, sounds like some disk problems. But I still question whether the corruption is caused strictly by the number of files. I'm thinking that there is a different root cause. Whatever is causing this anomalous mounting behavior could be causing your file corruption as well.

I've never seen that kind of corruption in all my years, but that doesn't mean it doesn't exist. If there is proof that disks can be corrupted simply by creating too many files, I'd love to see it. I'm always willing to learn something new.


I just wrote and ran this script on one of my Yuns:

#!/usr/bin/python

count = 1
while True:
        name = "{:0>8d}.dat".format(count)
        print(name)
        file = open(name,'w')
        file.write("Test")
        file.close
        count = count + 1

I let it run long enough to write 10,022 files on a 32 GB SD card. I am experiencing no corruption: the file contents are correct and the directory listings are correct. The only issue I'm seeing comes to listing the files: the ls command is apparently trying to read the entire list of 10k files so it can sort it before display. This is apparently a difficult task for the Yun, as it takes about five minutes before anything is displayed, but I eventually get the proper response. If I try "ls 00001234.dat" I get a proper listing for that entry, so I'm confident that the directory is intact. And if I "cat 00000001.dat" I get the proper contents. They work with any file name picked out at random. And I see no corruption elsewhere on the SD card.

ShapeShifter:
Are all of these files going in the root directory, or in a sub directory? If you are putting them in the root, try putting them in a sub directory.

Files are in many subdirectories and I can't change that: files are "tiles" from OpenStreetMap and the system relies on names of files and name of folders to find the "tile" according to GPS values.

In order to understand: the system has as many folders than zoom levels. Inside each "level zoom folder" you have folders with, each one, the zone the X position on earth, and, on each X folder, "tiles" which name = position Y.

Actually, I've have the crash with pictures for a part of the country, at zoom 12,13,14,15 and 16. As I need to go up to zoom 19, and as ALL tiles are 256x256, it's easy to understand that, at zoom 17,18 and 19, the number of file increase a lot.

I'll tried to re-init the Arduino. If result is the same, I'll use a real computer as a server or I'll try to use a USB driver to see If the result is better.

Thanks
PL