LBA NAND Testing
As part of testing storage devices for suitability for future generations of XO Laptops, Toshiba LBA NAND parts were placed onto production XO motherboards and tested. The devices failed catastrophically quite early in the testing process.
History
The tests started with eight XOs at 1CC modified with a 4GB LBA-NAND part. Mitch Bradley prepared a kernel that has the drivers for the LBA-NAND connected through the CaFE chip. He also has a BusyBox initrd which supports partitioning, ext2 formatting, and testing of the parts. Testing started 9/22/08.
By 12/01/08, five of the 4GB devices had failed. Three had failed catastrophically, and could not be accessed (or reformatted) anymore. All devices lost their MBR (located in the first logical block on the device) upon failure. This failure might have been excerbated by a flaw in the original initialization process which placed the MBR in the same erase block as the beginning of the ext2 file system. These five devices were returned to Toshiba for failure analysis, and replaced with new 2GB LBA-NAND devices. Testing was resumed on the new devices.
By 3/10/08, all the 2GB parts, and all but one of the 4GB parts had failed.
Test Estimate
In the case of the LBA-NAND parts, we fill all but 32 MB of the media (leaving 16K blocks). Assume the device withholds 6% of the blocks for wear leveling and bad block replacement (120K blocks). Assuming naive wear leveling, this should result in a write failure in approx. 136K x 5K or 680M block writes (1.4 TB writen). We can continue to write at approx. 350 blocks (0.7 MB) per second, giving a time to failure of 22 days.
The current test program only writes in step 4.2, giving 20 MB/45 sec., or 220 blocks per second. This gives a times to failure of 35 days. But at the same time it is performing storage error rate testing at 42K blocks/sec --- checking the entire 4 GiB device 40 times a day.
The test rates were 14-16 sec/test step 4.1 and 13-16 sec/test step 4.2. This translates into roughly a 4 MByte/s read rate, and 0.7 MByte/s write rate (this test version wrote 10MB, and did no read testing). This is verified by later tests with a 34 sec. mean time for step 4.2, when both reading back 20 MiB of data and writing 20 MiB of data.
Endurance Results
| Laptop | Serial # | Test | Total Written | Comments |
|---|---|---|---|---|
| LBA1 | CSN74700D03 | Wear & Error | 4906 | |
| LBA2 | CSN74702D30 | Wear & Error | 4882 | device failed |
| LBA3 | SHF808021E4 | Wear & Error | 985 | Device failed (sample #1) |
| LBA4 | CSN749013AF | Wear & Error | 2467 | Device Failed (sample #3) |
| LBA5 | CSN75001985 | Wear & Error | 2111 | Device failed (sample #4) |
| LBA6 | CSN74702A8E | Wear & Error | 2491 | Device failed (sample #5) |
| LBA7 | CSN748040B6 | Wear & Error | 3022 | device failed |
| LBA8 | CSN74900B3C | Wear & Error | 2329 | Device failed (sample #2) |
| LBA13 | SHF808021E4 | Wear & Error | 1645 | 2 GiB part - device failed |
| LBA14 | CSN749013AF | Wear & Error | 120 ? | 2 GiB part - device failed |
| LBA15 | CSN75001985 | Wear & Error | 120 ? | 2 GiB part - device failed |
| LBA16 | CSN74702A8E | Wear & Error | 2269 | 2 GiB part - device failed |
| LBA18 | CSN74900B3C | Wear & Error | 120 ? | 2 GiB part - device failed |
More test results are available
Total Written refers to the total amount of data written to date to the storage device in an attempt to test wear levelling and W/E lifetime, in GiB. For the current tests, each pass is 0.02 GiB.
LBA-NAND Setup Notes
Boot with a USB stick containing two directories:
- boot
- vmlinuz
- initrd.gz
- olpc.fth
- test.sh - a script for running the wear leveling and error checking test
After the laptop boots, type the following to mount the USB disk for the first time:
mount /usb
At this point, some dangerous sounding error messages will result. Ignore them. If this is the first time, see the next section. If restarting a test, now simply type:
/usb/test.sh
A new logfile will automatically be created on the USB key (in /usb).
fsck
Occasionally, the ext2 filesystem on the NAND device becomes corrupted. You can repair it using:
umount /nand /sbin/fsck.ext2 /dev/lba1 mount /dev/lba1 /nand
LBA-NAND Initialization
Note: For these tests to have a valid effect, the storage device should not be re-formatted or re-initialized for the duration of the wear leveling test! Do not run fill_cp.sh unless you are starting the tests for the first time!
The /etc/init.d/rc.usbnandtest script attempts to mount the storage device at boot time. Unmount it with:
umount /nand
To partition the disk, use fdisk:
fdisk /dev/lba
Delete any existing partitions, and create a single partition using all available space. Tell fdisk to start the first partition at sector number 512 - that aligns on a 256K boundary which is a multiple of the erase block size for this generation and probably the next.
With the version of fdisk in busybox, use the 'u' command to switch to sector units - it should respond with "Changing display/entry units to sectors". Then when you add the first partition, tell it 512 for the start. It defaults to cylinder units, which is a problem because the goofy old DOS conventions for the maximum values for SPT, tracks, and heads combine in strange ways to give non-power-of-two cylinder sizes.
Then proceed with creating a partition. Hit this series of keys: n <CR> p <CR> 1 <CR> 512 <CR> <CR> w <CR>.
After partitioning, dump the MBR and verify that the partition table is right. You should see something like this:
dd if=/dev/lba bs=32K count=1 | od -b
00000700: xxx xxx 203 xxx xxx xxx 000 002 000 000 yy yy yy yy 00 00
Look for the "000 002 000 000" - that's 0x200 in hex little endian, i.e. starting block 512. (The 203 (hex 83) is the ext2 type code.)
Now, use mke2fs to place a filesystem on the partition, forcing a 2K block size and no space reserved for root:
mke2fs -m 0 -b 2048 /dev/lba1
Now you can mount it and start filling it:
mount /dev/lba1 /nand /usb/fill_cp.sh
As the kernel provided doesn't include support for /dev/urandom, the method used was to provide the random data on a USB key. fill_cp.sh just copies it from /usb/random. The USB key was previously initialized with sufficient random data using the fill_random.sh command. This command takes a number of 32 MB random data files to generate as an argument (65 files is sufficient for 4 GiB devices):
mkdir /Volumes/USBKEY/random cd /Volumes/USBKEY/random ~/NANDtest/fill_random.sh 65
Original LBA-NAND Initialization
The first time this test was conducted, the devices were initialized using slightly simpler instructions, which resulted in the MBR being in the same erase block as the start of the ext2 filesystem. This resulted in a failure mode where the device formatting was lost.
The difference with the above instructions for initializing were the command used to repartition the storage device:
fdisk /dev/lba
Delete any existing partitions, and create a single partition using all available space. Hit this series of keys: d <CR> n <CR> p <CR> 1 <CR> <CR> <CR> w <CR>.
And the command used to format the device didn't force a small block size:
mke2fs -m 0 /dev/lba1