DSM 6.x und darunter Frage zu meinem bestehenden SHR-Setup

[MattCB]

Ich habe mir heute mal per Shell das Setup meiner Festplatten angeschaut. Auf den beiden Festplatten sind 2 Partitionen mit jeweils 1 TB Speicherplatz angelegt und es gibt insgesamt 4 RAID-Einträge (md0 bis md3).

Kann es sein, dass diese Konfiguration daher kommt, dass ich vorher 2 * 1 TB verbaut hatte und die HDDs dann nacheinander durch 2 * 2 TB ersetzt habe? Vermutlich hat DSM dann den Speicherplatz erweitert, indem es einfach auf jeder Platte eine neue Partition angelegt hat und diese dann dem bestehenden SHR hinzugefügt hat?

Ich gehe mal davon aus, dass ich dadurch keine Nachteile habe. Die beiden Partitionen pro HDD zu einer zusammenzulegen wird sicherlich nicht ohne Datenverlust gehen.

 

[Benares]

Nö, das ist völlig normal. Bei internen Platten liegt der DSM erstmal als Raid1 in der 1. Partition aller Platten (md0), dann folgt eine 2. Partition, auch als Raid1, für den Swap-Bereich (md1). Erst ab der 3. Partition erfolgt die benutzerdefinierbare Aufteilung abhängig vom gewählten Raid-Typ für die Daten (mdx).

 

[EDvonSchleck]

Ich denke die Frage war eher warum es nicht die üblichen 3 Partitionen sind. Die 3. Partition entspricht der ersten originalen Größe vor dem erweitern. Die 4. Partition der Rest nach dem erweitern. Ich denke @MattCB würde gerne wissen warum die 3. Partition nicht erweitert wurde sondern eine neue hinzugefügt wird.

 

[Benares]

Ah, ok - mag sein.
Dann müsste man mal schauen, was "vgdisplay", "lvdisplay" und "mount" so ausgibt. Kann schon sein, dass der DSM noch ein weiteres Raid1 draufgesetzt und per LVM wieder vereinigt hat.

 

[MattCB]

Danke schon mal für die Antworten. Es wird so sein wie ich vermutet habe. Die DS hat einfach eine zweite Partition hinter die erste 1TB-Partition gehängt und dem RAID hinzugefügt. Deshalb wird SHR wohl als so flexibel von Synology beworben. Aber solange man den Platz komplett nutzen kann, sollte das ja egal sein. Eine einfache Vergrößerung der "alten" 1 TB Partition wird wohl nicht ohne Datenverluste gehen.

Ich habe mal die Ausgaben von vgdisplay, lvdisplay und mount angehangen, aber nicht als Screenshot. Ich wusste gar nicht, dass auf so einer DS so viel gemounted wird. Aber einiges davon wird wohl von Docker und dem VMM sein.

Spoiler

Ausgabe von vgdisplay:

 --- Volume group ---
  VG Name               vg1000
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               1.81 TiB
  PE Size               4.00 MiB
  Total PE              475749
  Alloc PE / Size       475749 / 1.81 TiB
  Free  PE / Size       0 / 0
  VG UUID               71CokL-fu6j-h9jo-AK5z-dBQj-Joau-3zE8sy
 
  Ausgabe von lvdisplay:
 
  --- Logical volume ---
  LV Path                /dev/vg1000/lv
  LV Name                lv
  VG Name                vg1000
  LV UUID                KJQi11-y9CJ-5i6D-ZOkb-QPTj-6u4U-qe4HeO
  LV Write Access        read/write
  LV Creation host, time ,
  LV Status              available
  # open                 1
  LV Size                1.81 TiB
  Current LE             475749
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     384
  Block device           249:0
 
  Ausgabe von Mount:
 
  /dev/md0 on / type ext4 (rw,noatime,data=ordered)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=4978716k,nr_inodes=1244679,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/synomonitor type cgroup (rw,nosuid,nodev,noexec,relatime,name=synomonitor)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /proc/bus/usb type devtmpfs (rw,nosuid,size=4978716k,nr_inodes=1244679,mode=755)
tmpfs on /run/user/196791 type tmpfs (rw,nosuid,nodev,relatime,size=1003144k,mode=700,uid=196791,gid=196791)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,nosuid,nodev,noexec,relatime)
/dev/mapper/cachedev_0 on /volume1 type btrfs (rw,nodev,noatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,syno_allocator,subvolid=257,subvol=/@syno)
none on /config type configfs (rw,nosuid,nodev,noexec,relatime)
synodedup-fused on /volume1/ActiveBackupforBusiness/ActiveBackupData type fuse.synodedup-fused (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
/dev/mapper/cachedev_0 on /volume1/@docker/btrfs type btrfs (rw,nodev,noatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,syno_allocator,subvolid=257,subvol=/@syno/@docker/btrfs)
tmpfs on /dev/virtualization type tmpfs (rw,nosuid,nodev,noexec,noatime,size=1073741824k,mode=700)
nsfs on /run/docker/netns/a278f8fcd09c type nsfs (rw)
gvfsd-fuse on /var/tmp/user/1026/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1026,group_id=100,allow_other)
/dev/loop0 on /volume1/@ActiveBackup/agent/18428 type fuseblk.ntfs (ro,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
/dev/loop1 on /volume1/@ActiveBackup/agent/21231 type fuseblk.ntfs (ro,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
nsfs on /run/docker/netns/4097b16bc890 type nsfs (rw)
nsfs on /run/docker/netns/default type nsfs (rw)

 

[Benares]

Ja, dann ist es wohl so wie vermutet. Ich hätte da jetzt auch erwartet, dass die vorhandene Partition in so einem Fall erweitert wird. Man lernt immer noch was dazu.