У нас странное поведение: мы больше не можем перемещать файлы в определенный каталог. Мы получили
lstat("NewBatches/R910140805849312.dat", {st_mode=S_IFREG|0644, st_size=2850, ...}) = 0
lstat("Imported/R910140805849312.dat", 0x7fff10424b90) = -1 ENOENT (No such file or directory)
rename("NewBatches/R910140805849312.dat", "Imported/R910140805849312.dat") = -1 ENOSPC (No space left on device)
Но мы можем скопировать файл в папку. Осталось много места на диске, а также индексные дескрипторы. И мы не можем переместить файл только в этот подкаталог Imported. Все остальные работают в той же файловой системе EXT3.
Я немного озадачен
# tune2fs -l /dev/mapper/vgdmscsp-lvmaspdoc
tune2fs 1.39 (29-May-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: b4215e24-2285-46de-8398-f41bc3174b8e
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 33382400
Block count: 52428800
Reserved block count: 2619904
Free blocks: 5432592
Free inodes: 17432375
First block: 1
Block size: 1024
Fragment size: 1024
Reserved GDT blocks: 176
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 5216
Inode blocks per group: 652
Filesystem created: Thu Oct 6 11:19:53 2011
Last mount time: Sat Jul 12 09:26:56 2014
Last write time: Tue Aug 5 00:04:31 2014
Mount count: 40
Maximum mount count: -1
Last checked: Thu Oct 6 11:19:53 2011
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: b975b5a1-72ad-44a4-8c53-622f7ba71e25
Journal backup: inode blocks
Количество ваших бесплатных блоков не так уж и далеко от зарезервированного.
Block count: 52428800
Reserved block count: 2619904
Free blocks: 5432592
Во время создания файловая система ext3 резервирует процент блоков для использования пользователем root, который по умолчанию составляет 5%. Это позволяет процессам, принадлежащим root, продолжать запись на диск, блокируя пользовательское пространство, которое, как можно надеяться, является источником раздува диска.
Я подозреваю, что вы столкнулись с этой проблемой как непривилегированный пользователь, когда количество свободных блоков было меньше зарезервированного. В cp удалось бы, если бы вы вмешивались как root. Если вы можете подтвердить, что проблема исчезла, а текущее количество свободных блоков превышает зарезервированное количество, это наиболее вероятная причина.