Dateisystem wird nicht angezeigt, obwohl vorhanden

  • OMV4

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Dateisystem wird nicht angezeigt, obwohl vorhanden

    Hallo Community,

    ich bin neu hier und bin von Freenas auf OMV (4.1.19-1) umgestiegen.
    Ich habe ein Hardware RAID 5 mit WD RED 5TB HDD und wollte meinen unter Freenas erstellten ZFS Pool weiterverwenden. Ich bin aber davon abgekommen* und habe nun ein ext4 Filesystem auf dem RAID erstellt.
    Das war soweit auch erfolgreich, aber das Dateisystem taucht unter dem Menüpunkt Datenspeicher --> Dateisystem nicht auf!
    Unter den Laufwerken ist es vorhanden.
    Mit ssh und blkid wird das Laufwerk auch nicht erkannt ?(
    mit cat /proc/partitions aber sehr wohl
    mit fsck.ext4 -n /dev/sda1 kommt das hier

    Quellcode

    1. e2fsck 1.43.4 (31-Jan-2017)
    2. RAID5Datengrab: sauber, 11/305070080 Dateien, 19525118/2440557819 Blöcke
    Kann mir jemand meinen Fehler zeigen? Was muss ich anders machen? Stutzig macht mich vor allem der fehlende Eintrag in blkid.
    Übrigens: Neu erstellen kann ich das Dateisystem, aber es zeigt dasselbe Verhalten.

    *Grund: Ständige Neuvergabe von UUID nach Neustart und anschließendem Nichteinrichten der Freigaben.
  • Wie schon gesagt in der blkid wird es nicht angezeigt (dev/sda)

    Quellcode

    1. /dev/sdb2: LABEL="noRAID_Seagate" UUID="4834466464507399063" UUID_SUB="16045877241050624690" TYPE="zfs_member" PARTUUID="6b85b5f7-a815-11e7-96ab-d0509953b5f2"
    2. /dev/sdc1: UUID="1f499ddb-37e3-4f14-b149-58dd162b447d" TYPE="ext4" PARTUUID="c0eca847-01"
    3. /dev/sdc5: UUID="d567cdec-9bdb-42f2-a318-2fc80bae9f60" TYPE="swap" PARTUUID="c0eca847-05"
    4. /dev/sdd1: UUID="7157821f-8a80-4241-b8d0-0cdcb5a0786d" TYPE="ext4" PARTLABEL="WDMyBook10TB" PARTUUID="0d323e1d-9393-4bef-a2c0-fa6f6b1b3cf5"
    5. /dev/sdb1: PARTUUID="6b73ed3f-a815-11e7-96ab-d0509953b5f2"


    cat /proc/partitions

    Quellcode

    1. major minor #blocks name
    2. 8 0 9762232320 sda
    3. 8 1 9762231279 sda1
    4. 8 16 7814026584 sdb
    5. 8 17 2097152 sdb1
    6. 8 18 7811929348 sdb2
    7. 8 32 117220824 sdc
    8. 8 33 109136896 sdc1
    9. 8 34 1 sdc2
    10. 8 37 8081408 sdc5
    11. 8 48 9766436864 sdd
    12. 8 49 9766434816 sdd1
    Alles anzeigen
    cat /etc/fstab

    Quellcode

    1. # /etc/fstab: static file system information.
    2. #
    3. # Use 'blkid' to print the universally unique identifier for a
    4. # device; this may be used with UUID= as a more robust way to name devices
    5. # that works even if disks are added and removed. See fstab(5).
    6. #
    7. # <file system> <mount point> <type> <options> <dump> <pass>
    8. # / was on /dev/sda1 during installation
    9. UUID=1f499ddb-37e3-4f14-b149-58dd162b447d / ext4 errors=remount-ro 0 1
    10. # swap was on /dev/sda5 during installation
    11. UUID=d567cdec-9bdb-42f2-a318-2fc80bae9f60 none swap sw 0 0
    12. tmpfs /tmp tmpfs defaults 0 0
    13. # >>> [openmediavault]
    14. /dev/disk/by-label/hmmmmalt /srv/dev-disk-by-label-hmmmmalt ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
    15. /dev/disk/by-id/usb-WD_My_Book_25EE_4A4548454A5A384E-0:0-part1 /srv/dev-disk-by-id-usb-WD_My_Book_25EE_4A4548454A5A384E-0-0-part1 ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
    16. /RAID5_Datengrab/MEDIA/ /export/MEDIA none bind,nofail,_netdev 0 0
    17. /RAID5_Datengrab/Eigene\040Dateien /export/EigeneDateien none bind,nofail,_netdev 0 0
    18. /noRAID_Seagate/hmmmm /export/hmmmm none bind,nofail,_netdev 0 0
    19. # <<< [openmediavault]
    Alles anzeigen
  • dumpe2fs /dev/sda1

    Quellcode

    1. dumpe2fs 1.43.4 (31-Jan-2017)
    2. Filesystem volume name: RAID5Datengrab
    3. Last mounted on: <not available>
    4. Filesystem UUID: 49d2a9b3-a3c3-49c7-8790-7cc53b3eaa7b
    5. Filesystem magic number: 0xEF53
    6. Filesystem revision #: 1 (dynamic)
    7. Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
    8. Filesystem flags: signed_directory_hash
    9. Default mount options: user_xattr acl
    10. Filesystem state: clean
    11. Errors behavior: Continue
    12. Filesystem OS type: Linux
    13. Inode count: 305070080
    14. Block count: 2440557819
    15. Reserved block count: 0
    16. Free blocks: 2421032701
    17. Free inodes: 305070069
    18. First block: 0
    19. Block size: 4096
    20. Fragment size: 4096
    21. Group descriptor size: 64
    22. Reserved GDT blocks: 884
    23. Blocks per group: 32768
    24. Fragments per group: 32768
    25. Inodes per group: 4096
    26. Inode blocks per group: 256
    27. Flex block group size: 16
    28. Filesystem created: Fri Mar 22 10:53:20 2019
    29. Last mount time: n/a
    30. Last write time: Fri Mar 22 11:01:41 2019
    31. Mount count: 0
    32. Maximum mount count: -1
    33. Last checked: Fri Mar 22 10:53:20 2019
    34. Check interval: 0 (<none>)
    35. Lifetime writes: 74 GB
    36. Reserved blocks uid: 0 (user root)
    37. Reserved blocks gid: 0 (group root)
    38. First inode: 11
    39. Inode size: 256
    40. Required extra isize: 32
    41. Desired extra isize: 32
    42. Journal inode: 8
    43. Default directory hash: half_md4
    44. Directory Hash Seed: d8ffc742-e54a-4548-8376-0a1b3339edac
    45. Journal backup: inode blocks
    46. Checksum type: crc32c
    47. Checksum: 0xf59f5fcf
    48. Jounaleigenschaften: (none)
    49. Journalgröße: 1024M
    50. Journal-Länge: 262144
    51. Journal-Sequenz: 0x00000001
    52. Journal-Start: 0
    53. Gruppe 0: (Blöcke 0-32767) csum 0x0c1c [ITABLE_ZEROED]
    54. Primär Superblock in 0, Gruppendeskriptoren in 1-1164
    55. reservierte GDT-Blöcke bei 1165-2048
    56. Block-Bitmap in 2049 (+2049), csum 0xb08d8bd9
    57. Inode bitmap at 2065 (+2065), csum 0x250b7cb9
    58. Inode-Tabelle in 2081-2336 (+2081)
    59. 26585 freie Blöcke, 4085 freie Inodes, 2 Verzeichnisse, 4085 ungenutzte Inodes
    60. Freie Blöcke: 6183-32767
    61. Freie Inodes: 12-4096
    62. Gruppe 1: (Blöcke 32768-65535) csum 0xe7c5 [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
    63. Datensicherung Superblock in 32768, Gruppendeskriptoren in 32769-33932
    64. reservierte GDT-Blöcke bei 33933-34816
    65. Block-Bitmap in 2050 (bg #0 + 2050), csum 0x00000000
    66. Inode bitmap at 2066 (bg #0 + 2066), csum 0x00000000
    67. Inode-Tabelle in 2337-2592 (bg #0 + 2337)
    68. 30719 freie Blöcke, 4096 freie Inodes, 0 Verzeichnisse, 4096 ungenutzte Inodes
    69. Freie Blöcke: 34817-65535
    70. Freie Inodes: 4097-8192
    71. Gruppe 2: (Blöcke 65536-98303) csum 0x9124 [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
    72. Block-Bitmap in 2051 (bg #0 + 2051), csum 0x00000000
    73. Inode bitmap at 2067 (bg #0 + 2067), csum 0x00000000
    74. Inode-Tabelle in 2593-2848 (bg #0 + 2593)
    75. 32768 freie Blöcke, 4096 freie Inodes, 0 Verzeichnisse, 4096 ungenutzte Inodes
    76. Freie Blöcke: 65536-98303
    77. Freie Inodes: 8193-12288
    78. Gruppe 3: (Blöcke 98304-131071) csum 0x652c [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
    79. Datensicherung Superblock in 98304, Gruppendeskriptoren in 98305-99468
    80. reservierte GDT-Blöcke bei 99469-100352
    81. Block-Bitmap in 2052 (bg #0 + 2052), csum 0x00000000
    82. Inode bitmap at 2068 (bg #0 + 2068), csum 0x00000000
    83. Inode-Tabelle in 2849-3104 (bg #0 + 2849)
    84. 30719 freie Blöcke, 4096 freie Inodes, 0 Verzeichnisse, 4096 ungenutzte Inodes
    85. Freie Blöcke: 100353-131071
    86. Freie Inodes: 12289-16384
    87. Gruppe 4: (Blöcke 131072-163839) csum 0x1742 [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
    88. Block-Bitmap in 2053 (bg #0 + 2053), csum 0x00000000
    89. Inode bitmap at 2069 (bg #0 + 2069), csum 0x00000000
    90. Inode-Tabelle in 3105-3360 (bg #0 + 3105)
    91. 32768 freie Blöcke, 4096 freie Inodes, 0 Verzeichnisse, 4096 ungenutzte Inodes
    92. Freie Blöcke: 131072-163839
    93. Freie Inodes: 16385-20480
    94. Gruppe 5: (Blöcke 163840-196607) csum 0xce2e [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
    95. Datensicherung Superblock in 163840, Gruppendeskriptoren in 163841-165004
    96. reservierte GDT-Blöcke bei 165005-165888
    97. Block-Bitmap in 2054 (bg #0 + 2054), csum 0x00000000
    98. Inode bitmap at 2070 (bg #0 + 2070), csum 0x00000000
    99. Inode-Tabelle in 3361-3616 (bg #0 + 3361)
    100. 30719 freie Blöcke, 4096 freie Inodes, 0 Verzeichnisse, 4096 ungenutzte Inodes
    101. Freie Blöcke: 165889-196607
    102. Freie Inodes: 20481-24576
    Alles anzeigen
    usw.
  • dmesg | grep sdb

    Quellcode

    1. [ 2.775384] sd 1:0:0:0: [sdb] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB)
    2. [ 2.775388] sd 1:0:0:0: [sdb] 4096-byte physical blocks
    3. [ 2.775406] sd 1:0:0:0: [sdb] Write Protect is off
    4. [ 2.775410] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
    5. [ 2.775438] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    6. [ 2.827665] sdb: sdb1 sdb2
    7. [ 2.828774] sd 1:0:0:0: [sdb] Attached SCSI disk

    dmesg | grep sda

    Quellcode

    1. [ 2.775328] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
    2. [ 2.775348] sd 0:0:0:0: [sda] 19524464640 512-byte logical blocks: (10.00 TB/9.09 TiB)
    3. [ 2.775363] sd 0:0:0:0: [sda] Write Protect is off
    4. [ 2.775366] sd 0:0:0:0: [sda] Mode Sense: 12 00 10 08
    5. [ 2.775389] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
    6. [ 2.775570] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
    7. [ 2.809605] sda: sda1
    8. [ 2.810153] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
    9. [ 2.810203] sd 0:0:0:0: [sda] Attached SCSI removable disk
    10. [ 860.294765] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
    11. [ 3480.194063] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
    12. [ 3480.195214] sda: sda1
    13. [ 3481.203406] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
    14. [ 3481.205000] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
    15. [ 3482.231087] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
    16. [ 3482.233195] sda: sda1
    17. [ 3483.207817] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
    18. [ 3483.209673] sda: sda1
    Alles anzeigen
    Ist die Festplatte zu groß?
  • Kein Backport Kernel. 4.19.0-0.bpo.2-amd64
    Ich habe mittlerweile die Vermutung, dass da noch einige Reste des ZFS auf dem RAID rumkreuchen.
    Ich habe mit makefs.ext4 nämlich die Fehlermeldung bekommen, dass ein zfs gefunden wurde. Das habe ich überschrieben, aber trotzdem keine Änderung.
    Ich baue morgen das NAS aus und erzeuge einen neuen RAID5 Verbund. Mal sehen ob es dann klappt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von schnuggler ()

  • wenn du komplett neu erzeugst, kannst du die ersten MB jeder Platte mal platt machen mit:
    dd if=/dev/null of=<dev> bs=1M count=10
    dann wird da sicher nichts mehr gefunden.
    SW: OMV 4.1.22 (Arrakis), Snapraid mit mergerfs, Minidlna
    MSI B150M ECO, Intel Pentium G4400, 16GB Kingston DDR4, SSD 250GB, 4TB Daten, 3*8TB+6TB SnapRaid (8TB Parity,3+3+2TB Parity2), FSP Aurum S 400W, Fractal Node 804
  • ok, jetzt ist das erste Mal, dass du uns sagst, dass du einen RAID controller verwendest, also ein HW RAID hast.
    wichtig wäre es, die Platten mal einzeln am Beginn zu löschen. Dann kann nichts mehr von Linux gefunden werden.
    eventuell reicht es auch, das RAID device am Anfang zu Nullen.
    SW: OMV 4.1.22 (Arrakis), Snapraid mit mergerfs, Minidlna
    MSI B150M ECO, Intel Pentium G4400, 16GB Kingston DDR4, SSD 250GB, 4TB Daten, 3*8TB+6TB SnapRaid (8TB Parity,3+3+2TB Parity2), FSP Aurum S 400W, Fractal Node 804
  • noch etwas: so ein HW RAID Controller hat einiges Intelligenz und auch internen (non-volatile) Speicher, in dem er die Konfiguration zusätzlich zur Info auf den Platten speichert. Diese Intelligenz müssen wir überlisten.
    hast du schon mal versucht, alle Partitions zu löschen und eventuell eine mini 1. Partition zu machen und das RAID als zweite?
    SW: OMV 4.1.22 (Arrakis), Snapraid mit mergerfs, Minidlna
    MSI B150M ECO, Intel Pentium G4400, 16GB Kingston DDR4, SSD 250GB, 4TB Daten, 3*8TB+6TB SnapRaid (8TB Parity,3+3+2TB Parity2), FSP Aurum S 400W, Fractal Node 804
  • Hallo wtuppa,

    in post#1 habe ich bereits geschrieben, dass ich ein Hardware RAID einsetze. ;)
    Ich habe die Gelegenheit genutzt und mir direkt 3 neue größere Platten gekauft und baue damit gerade ein neues RAID5. Die 10TB waren sowieso immer zu klein :D
    Die alten Platten werde ich in einem zu bauenden Backup-Server dann einsetzen.

    Mal sehen wie das dann klappt.
    Ich denke auch, dass es so war wie du vermutest, dass das Problem in der "Intelligenz" des Raid Controllers liegt.
  • sorry, hatte ich irgendwie überlesen. Vielleicht ist es auch am UHD Monitor mit 100% die Schrift manchmal doch etwas klein...
    mit neuen Platten sollte es auf jeden Fall klappen.
    Du weisst aber schon, dass RAID5 heutzutage nicht mehr wirklich viel Sicherheit bringt (wegen den Riesenplatten). Und sind das wirklich alles externe Platten?
    Wieso verwendest du eigentlich RAID5? Ändern sich deine Daten so häufig?
    SW: OMV 4.1.22 (Arrakis), Snapraid mit mergerfs, Minidlna
    MSI B150M ECO, Intel Pentium G4400, 16GB Kingston DDR4, SSD 250GB, 4TB Daten, 3*8TB+6TB SnapRaid (8TB Parity,3+3+2TB Parity2), FSP Aurum S 400W, Fractal Node 804
  • Ich verwende RAID5 um den Ausfall einer Platte abzusichern. Ist mir übrigens schon passiert.
    Daten ändern sich nicht häufig, aber bisher habe ich für den Großteil der Daten keine Sicherung, da ich diese - wenn auch umständlich - wieder beschaffen kann.
    Platten sind interne WD RED (sowohl alt als auch neu).
    Wenn ich mal den neuen BackUp Server laufen habe, denke ich auch darüber nach das RAID5 aufzulösen. Die Alternativen habe ich allerdings noch nicht komplett auf dem Schirm.
  • Re,

    mit dem RAID-Controller wird das so nix - weil Der seinen DCB schützt, und das heisst wiederrum, das man die "echten" ersten 4096 Byte auf den HDDs gar nicht löschen kann ... das kann nur der HW-Raid-Controller.

    Und dann noch die Frage nach dem Typ: ist es ein 5805 oder wirklich ein 5085?

    Und was das "Einbinde-Thema" angeht: man sollte mal versuchen, den Verbund per fstab einzubinden ... und schauen, was dann passiert.

    Sc0rp
  • Re,

    schnuggler schrieb:

    Es ist natürlich ein Adaptec ASR 5805.
    Also einen HW-RAID-Controller mit acht internen Ports und Dual-Core "RAID on Chip" (Den habe ich auch noch rumliegen - sogar wassergekühlt!). :thumbsup:

    Warum nicht RAID6? Oder ist das noch geplant? Wie sieht dein Backup-Konzept aus?

    Sc0rp
  • Sc0rp schrieb:

    mit dem RAID-Controller wird das so nix - weil Der seinen DCB schützt, und das heisst wiederrum, das man die "echten" ersten 4096 Byte auf den HDDs gar nicht löschen kann ... das kann nur der HW-Raid-Controller.
    darum meinte ich ja auch, die Platten mal an einen normalen SATA Anschluss (und nicht an den RAID Controller).

    schnuggler schrieb:

    Daten ändern sich nicht häufig, aber bisher habe ich für den Großteil der Daten keine Sicherung, da ich diese - wenn auch umständlich - wieder beschaffen kann.
    Platten sind interne WD RED (sowohl alt als auch neu).
    Könnte ja direkt ein Fall für SnapRAID sein. ist kein echtes RAID, sync muss händisch angestossen werden, allerdings sind alle Platten unabhängig voneinander, d.h. man braucht dann noch "mergerfs" um alles auf einmal zu sehen. Bei einem Plattenausfall sind die Daten aller anderen Platten noch voll verfügbar. Mit einer Parity kann nur dann alles wieder hergestellt werden, wenn seit dem letzten Sync keine Änderungen waren.
    SnapRAID kann übrigens mit verschiedenen Plattengrößen umgehen und bis zu 6 Parity Platten (wobei eine Parity mit Splt-Parity auf mehreren kleinen Platten liegen kann).
    SW: OMV 4.1.22 (Arrakis), Snapraid mit mergerfs, Minidlna
    MSI B150M ECO, Intel Pentium G4400, 16GB Kingston DDR4, SSD 250GB, 4TB Daten, 3*8TB+6TB SnapRaid (8TB Parity,3+3+2TB Parity2), FSP Aurum S 400W, Fractal Node 804
  • Hallo,

    vorerst bleibt es auf dem NAS bei RAID5.
    Ich bin wie gesagt gerade dabei den Backup Server zu planen, da ich jetzt 3x5TB Platten "rumliegen" habe und noch eine ganze Menge an Platten zwischen 2TB und 3TB.
    Für den Backup Server habe ich mich in das SnapRAID Thema eingelesen und finde das einen interessante Möglichkeit den Server zu realisieren.
    Eine 5TB und eine von den 3TB zur Parity zu machen und das Ganze Vogelfutter dann da rein zu hauen. Jetzt benötige ich nur noch genügend SATA Anschlüße :)
    Aktuell habe ich das Board im Auge: ASrock J3455B mit einem InLine 19054 SATA-Controller
    Oder ich rüste meinen aktuellen Surfrechner (ist ein ewig alter Athlon X2) zum Server um und hole mir stattdessen mal einen aktuellen Ryzen als Surfstation.