This seems be a bootrecord-erasure problem, rather than an
inode problem.

Recently, when I try to edit a file on </home/user> with
nano, it refuses to save the file, saying 'Error 22: No
space left on device'
When I close nano, the file is truncated to zero length
(fortunately, nano backed-up copies to the SD card). The
</home/user> files are still there, and readable, as long
as I don't edit them.
If I try to copy a file from </home/user/MyDocs> to
</home/user>, I get the same error message (but the file
isn't truncated - files on MyDocs can be edited).

Some pertinent <df>-results are as follows (sorry about the formatting collapse):

================================================== =================
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/mmcblk0p2 2064208 1966052 0 100% /home
/home/opt 2064208 1966052 0 100% /opt
(various /opt/pymaemo lines) ... 2064208 1966052 0 100% /usr/...
/dev/mmcblk0p1 28312128 27012544 1299584 95% /home/user/MyDocs
/dev/mmcblk1p1 15549952 14970720 579232 96% /media/mmc1
================================================== =================

1966/2064 is approx. 95%, not 100%. Deleting files from
/home/user causes the 'Used' value to drop.

I'll confess I don't understand the duplication of numbers -
does the partition have different filesystems written on
different sections? Or are some mount-names *aliases*?

The first 500 bytes - the bootrecord - of </dev/mmcblk0p2>
are all '/x00' - it's been zeroed-out, somehow. The first 500
bytes on the other two mmcblk partitions aren't all zero.

Here are some <fdisk> listings:

================================================== ==============

Disk /dev/mmcblk0p1: 29.0 GB, 28995223552 bytes
4 heads, 16 sectors/track, 884864 cylinders, total 56631296 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System

.................................................. .............

Disk /dev/mmcblk0p2: 2147 MB, 2147483648 bytes
4 heads, 16 sectors/track, 65536 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mmcblk0p2 doesn't contain a valid partition table

================================================== ==============

I had recently been installing and uninstalling programs
downloaded from the Net, by both direct compiling/installing,
and by dpkg or apt-get, often as root; also I may have
attempted to copy-in files too large for the available space.

What might have caused this bootrecord-erasure - is malware
the most likely reason? Any tips on how to safely fix it?
I can't run <fsck> because I don't know how to unmount
</dev/mmcblk0p2> (it says "device or resource busy").

Could a regular contributor please post a link to the first 500
bytes of N900's /dev/mmcblk0p2? Maybe writing that back is all
that's needed?

And you know that... how?

That would be because MyDocs is another partition.

That strongly indicates an inode problem. Your files take only 95%, but your files + metadata take the whole 100%.

Aliases.

That is OK.
mmcblk0p1 and mmcblk1p1 are FAT32, mmcblk0p2 is ext3. Different file systems, different byte patterns. I have just checked mine, the first 1000 bytes on mmcblk0p2 are all zeroes.

That's because it doesn't.
mmcblk0p2 is a partition, it does no contain one.

No.

https://talk.maemo.org/showthread.php?t=96510

It turns out I downloaded too much source-code into a directory
on </home/user>. Removing about a dozen large files fixed things.
So this was an out-of-memory, rather than out-of-inodes, problem?

I didn't have the <df -i> flag, however, I do have gdf (that's
'gnu-df'), and here's some selected (pre-fix) output:

"gdf -i":
================================================== ===================
================================================== ===================

Here's the selected <df> listing, post-fix:

"df":
---------------------------------------------------------------------
---------------------------------------------------------------------

Note, the odd output of fdisk actually was a clue - post-fix, it's
back to normal:

"fdisk -l":
================================================== ===================
================================================== ===================

The first 500 bytes of </dev/mmcblk0p2> are blank, as before.

Yes, sorry, my fault. As explained by wicket in the other thread, checking /opt will check only a small part of the /home partition and completely miss /home/user.

READ-ONLY FS

After the fix, </dev/mmcblk0p1> was left in a read-only state;
this was explained in dmesg:

[ 55.107116] slide (GPIO 71) is now open
[ 82.010894] FAT: Filesystem error (dev mmcblk0p1)
[ 82.010925] fat_get_cluster: invalid cluster chain (i_pos 0)
[ 82.010955] File system has been set read-only
[ 82.107360] FAT: Filesystem error (dev mmcblk0p1)
[ 82.107421] fat_get_cluster: invalid cluster chain (i_pos 0)
[ 104.927398] slide (GPIO 71) is now closed,

an open-and-shut case.

Unmounting the partition and running fsck cleared this up (apparently,
a couple of files had 'EOF errors').