Networkmanager Destroying Ssd

[ari64]

NetworkManager is damaging my SSD because of how frequently it rewrites the network configuration files. On my Acer Aspire One, it kills a block on the flash every few months. When this happens, the kernel prints out some errors and remounts the root filesystem read-only. After rebooting and running fsck, the block is remapped and it will work again for a few months until it destroys the new block. I know that eventually it will run out of spare blocks and the SSD will be unusable.

I haven't received my Pandora yet, but this is one problem that I'm not looking forward to. Is there any simple way to avoid this, other than turning off the wireless when you're not using it?

 

[Pickle]

NetworkManager is damaging my SSD because of how frequently it rewrites the network configuration files. On my Acer Aspire One, it kills a block on the flash every few months. When this happens, the kernel prints out some errors and remounts the root filesystem read-only. After rebooting and running fsck, the block is remapped and it will work again for a few months until it destroys the new block. I know that eventually it will run out of spare blocks and the SSD will be unusable.

I haven't received my Pandora yet, but this is one problem that I'm not looking forward to. Is there any simple way to avoid this, other than turning off the wireless when you're not using it?

maybe those files could be mounted to a ram drive?

 

[ari64]

maybe those files could be mounted to a ram drive?

Well, the files that fsck usually complained about were /etc/resolv.conf and the xml files from ~/.gconf/system/networking. Sometimes these files would end up in /lost+found.

Possibly you could make ~/.gconf a ram disk. I don't know what to do about /etc though.

The SSD in the Aspire One is a probably a cheapo MLC flash with a limit of about 10000 rewrites. I'm hoping the chip in the Pandora has better endurance, but still this could be a problem if you use wifi access points with a weak signal and it disconnects/reconnects every few minutes.

 

[paulguy]

Would be nice for someone to kinda watch to see how much is being written to the NAND while in use. Honestly, I think the NAND should be pretty much read only by default, then have maybe an icon to swap between read/write (mount / -o remount,rw) and read-only (mount / -o remount,ro). Anything that doesn't want to live in a read-only filesystem will have to be fixed. to not care.

 

[God Ginrai]

Would be nice for someone to kinda watch to see how much is being written to the NAND while in use. Honestly, I think the NAND should be pretty much read only by default, then have maybe an icon to swap between read/write (mount / -o remount,rw) and read-only (mount / -o remount,ro). Anything that doesn't want to live in a read-only filesystem will have to be fixed. to not care.

+1

-God Ginrai

 

[EvilDragon]

Interesting... going to dive into this.
Moving those files to a temp directory is easy - symlinks on startup would do.
Probably should include that into the NetworkManager Startup-Script.

 

[ari64]

Would be nice for someone to kinda watch to see how much is being written to the NAND while in use.

It might be useful to have the kernel keep some stats, but most applications don't write files that frequently. NetworkManager is the only application that I have seen regularly burn out flash blocks with normal usage.

EvilDragon: Making /etc/resolv.conf a symlink won't work, since it deletes and recreates this file (so deletes the symlink). You'll probably have to make a custom build of nm if you want it to create the file somewhere else.

 

[sebt3]

Well, the files that fsck usually complained about were /etc/resolv.conf and the xml files from ~/.gconf/system/networking. Sometimes these files would end up in /lost+found.

Possibly you could make ~/.gconf a ram disk. I don't know what to do about /etc though.

The SSD in the Aspire One is a probably a cheapo MLC flash with a limit of about 10000 rewrites. I'm hoping the chip in the Pandora has better endurance, but still this could be a problem if you use wifi access points with a weak signal and it disconnects/reconnects every few minutes.

As a user c an't write to /etc/resolv.conf, I guess that NM is re-reading that file again and again. Causing the access date to by updated in the parent inode.
Too many write at the same place kill nand and SDD. But don't worry pandora root filesystem is mounted "-noatime", hence no more multiple write at the same place...

But this scenario seems odd, why checking if a file don't change manually when FAM can do it for you for free (and without the read access)

 

[ari64]

As a user c an't write to /etc/resolv.conf, I guess that NM is re-reading that file again and again. Causing the access date to by updated in the parent inode.
Too many write at the same place kill nand and SDD. But don't worry pandora root filesystem is mounted "-noatime", hence no more multiple write at the same place...

But this scenario seems odd, why checking if a file don't change manually when FAM can do it for you for free (and without the read access)

NetworkManager rewrites this file every time it associates with a wireless access point, and again when it disconnects. I have the filesystem mounted with noatime, so it's not that. Under normal usage, it will typically burn out a block every few months, but I once stayed at a hotel with a really bad wireless network, and it would re-connect every few minutes. I ended up with several bad blocks in less than a week.

Since the files themselves are deleted and re-created, they can get written to various different blocks, but the re-writes eventually kill the directory/inode. The files then end up in /lost+found when fsck finds them.