Ausprobiert habe ich das noch nicht. 
Falls du das testen willst, dann musst du aber u.U. auch die Dateinamen ändern, auf die aktuellen. (Falls die anders sind)
Ach, so wichtig ist das nicht. Aber ich bin froh, dass ich diesen „Fehler“ jetzt gemacht habe, und nicht erst in einem Jahr... Finde es trotzdem noch schade, so kann ich meine Server nie umfunktionieren bzw. umbenennen oder gar in eine andere Gruppe stecken, ohne alle Daten zu „verlieren“ (Ja, ich weiß, sind noch vorhanden...)
Ich habe gerade den interessanten Befehl slabtop -s c gefunden mit dem man sich den Cache ansehen kann.
Da sehe ich bei mir hauptsächlich sehr viel Disk Caching. Ob das wirklich alles anzeigt, kann ich nicht beurteilen.
Objekte aktiv / gesamt (% benutzt) : 143800 / 145190 (99,0%)
Slabs aktiv / gesamt (% benutzt) : 5474 / 5474 (100,0%)
Caches aktiv / gesamt (% benutzt) : 111 / 159 (69,8%)
Größe aktiv / gesamt (% benutzt) : 34947,48K / 35378,58K (98,8%)
Minimum / Average / Maximum Object : 0,01K / 0,24K / 8,00K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
14868 14868 100% 0,62K 1239 12 9912K inode_cache
23709 23653 99% 0,19K 1129 21 4516K dentry
4763 4706 98% 0,70K 433 11 3464K proc_inode_cache
19648 19648 100% 0,12K 614 32 2456K kernfs_node_cache
1976 1976 100% 1,16K 152 13 2432K ext4_inode_cache
448 448 100% 4,00K 56 8 1792K kmalloc-4k
592 589 99% 2,00K 74 8 1184K kmalloc-2k
1568 1568 100% 0,57K 112 14 896K radix_tree_node
768 762 99% 1,00K 96 8 768K kmalloc-1k
950 935 98% 0,77K 95 10 760K shmem_inode_cache
22912 22766 99% 0,03K 179 128 716K lsm_inode_cache
105 93 88% 6,12K 21 5 672K task_struct
6240 6240 100% 0,10K 160 39 640K buffer_head
920 920 100% 0,50K 115 8 460K kmalloc-512
2730 2730 100% 0,15K 105 26 420K vm_area_struct
48 48 100% 8,00K 12 4 384K kmalloc-8k
80 66 82% 4,00K 10 8 320K biovec-max
160 160 100% 2,00K 20 8 320K kmalloc-cg-2k
1040 1029 98% 0,25K 65 16 260K kmalloc-256
1218 1218 100% 0,19K 58 21 232K kmalloc-192
3712 3656 98% 0,06K 58 64 232K kmalloc-64
105 84 80% 2,12K 7 15 224K sighand_cache
4088 4088 100% 0,05K 56 73 224K ftrace_event_field
182 158 86% 1,12K 13 14 208K signal_cache
784 711 90% 0,25K 49 16 196K cred_jar
1680 1579 93% 0,09K 40 42 160K kmalloc-96
1748 1748 100% 0,09K 38 46 152K trace_event_file
592 354 59% 0,25K 37 16 148K maple_node
330 330 100% 0,38K 33 10 132K mnt_cache
144 130 90% 0,88K 16 9 128K sock_inode_cache
32 32 100% 4,00K 4 8 128K kmalloc-cg-4k
1856 1682 90% 0,06K 29 64 116K anon_vma_chain
1856 1856 100% 0,06K 29 64 116K vmap_area
1014 1014 100% 0,10K 26 39 104K anon_vma
3328 3320 99% 0,03K 26 128 104K kmalloc-32
800 800 100% 0,12K 25 32 100K kmalloc-128
441 441 100% 0,19K 21 21 84K proc_dir_entry
5376 5375 99% 0,02K 21 256 84K kmalloc-16
38 38 100% 1,62K 2 19 64K bdev_cache
1530 1530 100% 0,04K 15 102 60K ext4_extent_status
784 518 66% 0,07K 14 56 56K Acpi-Operand
192 128 66% 0,25K 12 16 48K skbuff_head_cache
45 45 100% 1,06K 3 15 48K mm_struct
40 40 100% 1,00K 5 8 40K kmalloc-cg-1k
160 160 100% 0,25K 10 16 40K kmem_cache
72 72 100% 0,50K 9 8 36K kmalloc-cg-512
176 176 100% 0,18K 8 22 32K ext4_groupinfo_4k
22 22 100% 1,38K 2 11 32K UDPv6
13 13 100% 2,38K 1 13 32K TCPv6
14 14 100% 2,25K 1 14 32K TCP
34 34 100% 0,91K 2 17 32K request_queue
Alles anzeigen
Objekte aktiv / gesamt (% benutzt) : 844659 / 856722 (98,6%)
Slabs aktiv / gesamt (% benutzt) : 27031 / 27031 (100,0%)
Caches aktiv / gesamt (% benutzt) : 117 / 163 (71,8%)
Größe aktiv / gesamt (% benutzt) : 179805,29K / 181205,62K (99,2%)
Minimum / Average / Maximum Object : 0,01K / 0,21K / 8,00K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
64844 64844 100% 1,16K 4988 13 79808K ext4_inode_cache
293631 292985 99% 0,10K 7529 39 30116K buffer_head
103173 103072 99% 0,19K 4913 21 19652K dentry
19964 19964 100% 0,57K 1426 14 11408K radix_tree_node
15012 15012 100% 0,62K 1251 12 10008K inode_cache
116892 108894 93% 0,04K 1146 102 4584K ext4_extent_status
8600 8432 98% 0,50K 1075 8 4300K kmalloc-512
5511 5457 99% 0,70K 501 11 4008K proc_inode_cache
52096 52034 99% 0,06K 814 64 3256K vmap_area
86784 86524 99% 0,03K 678 128 2712K lsm_inode_cache
20544 20544 100% 0,12K 642 32 2568K kernfs_node_cache
432 414 95% 4,00K 54 8 1728K kmalloc-4k
608 583 95% 2,00K 76 8 1216K kmalloc-2k
170 157 92% 6,12K 34 5 1088K task_struct
5082 5082 100% 0,19K 242 21 968K kmalloc-192
7008 7008 100% 0,12K 219 32 876K kmalloc-128
980 980 100% 0,77K 98 10 784K shmem_inode_cache
776 755 97% 1,00K 97 8 776K kmalloc-1k
4966 4966 100% 0,15K 191 26 764K vm_area_struct
96 64 66% 4,00K 12 8 384K biovec-max
48 48 100% 8,00K 12 4 384K kmalloc-8k
165 114 69% 2,06K 11 15 352K sighand_cache
176 167 94% 2,00K 22 8 352K kmalloc-cg-2k
1216 1175 96% 0,25K 76 16 304K kmalloc-256
4160 3937 94% 0,06K 65 64 260K kmalloc-64
3840 3642 94% 0,06K 60 64 240K anon_vma_chain
944 746 79% 0,25K 59 16 236K filp
4088 4088 100% 0,05K 56 73 224K ftrace_event_field
1989 1951 98% 0,10K 51 39 204K anon_vma
816 569 69% 0,25K 51 16 204K maple_node
2016 1597 79% 0,09K 48 42 192K kmalloc-96
140 115 82% 1,12K 10 14 160K signal_cache
1748 1748 100% 0,09K 38 46 152K trace_event_file
2432 2432 100% 0,06K 38 64 152K kmalloc-rcl-64
420 420 100% 0,31K 35 12 140K mnt_cache
136 129 94% 0,91K 8 17 128K request_queue
152 141 92% 0,81K 8 19 128K sock_inode_cache
120 74 61% 1,06K 8 15 128K mm_struct
32 32 100% 4,00K 4 8 128K kmalloc-cg-4k
112 75 66% 1,00K 14 8 112K kmalloc-cg-1k
3584 3545 98% 0,03K 28 128 112K kmalloc-32
90 90 100% 1,06K 6 15 96K UNIX
5888 5785 98% 0,02K 23 256 92K kmalloc-16
462 462 100% 0,19K 22 21 88K proc_dir_entry
121 121 100% 0,69K 11 11 88K files_cache
26 26 100% 2,38K 2 13 64K TCPv6
336 336 100% 0,19K 16 21 64K skbuff_ext_cache
840 456 54% 0,07K 15 56 60K Acpi-Operand
416 416 100% 0,12K 13 32 52K scsi_sense_cache
192 112 58% 0,25K 12 16 48K skbuff_head_cache
30 30 100% 1,56K 3 10 48K bdev_cache
Alles anzeigen
Naja, die Hauptunterschiede sind ja die Caches (Felder "cache", "slab_cache"), Dateien , Verzeichnisse, inodes usw. Bei Orilla hat das System wohl einfach mehr mit Dateien gearbeitet als bei Pangar, diese ins RAM geladen und sie dort belassen, weil das RAM seither nicht anderweitig benötigt wurde.
Der einzige Unterschied, der mir jetzt noch einfällt: Orilla ist ein zurückgespielter Snapshot, Pangar neu aufgesetzt. Aber der Snapshot von Orilla ist identisch mit der Installation von Pangar. Also sind vermutlich noch "Reste" von vor dem Snapshot im RAM?
