ilciumbia

January 5, 2017

Hi all,

I have just purchased a 4TB HDD which I would like to use purely for backup purposes. I have an XPEnology box with DSM5.2.5644.5 and a 3 volumes: RAID1, RAID5 and no RAID (actually they are all SHR, I used standard nomenclature to explain the redundancy).

My question is: should I install the new disk inside the XPEnology box, create a new volume (volume4) and use this as the backup destination or should I insert the HDD into a USB external box and backup everything there?

My thoughts:

Internal: no space on desk, as fast as it can get, protected from power surges and shortages BUT ext4 (so a bit more complex to access backup if needed), power always on, backup in the same place (and power source) as the data;

External: removable, NTFS makes access easier, powers off between backups BUT slower, heats up more

What do you guys think?

BTW: I tried to mount an internal drive as NTFS so that it is not part of DSM arrays, trying to get the best of both worlds, but it seems Synology has implemented a rather "unusual" way of dealing with fstab, so I can mount NTFS internal disks but they are not seen by DSM GUI so using them for backup makes things a little more cumbersome... Therefore I gave up.

Thanks!

November 25, 2016

Hi, thanks for the reply!

I sounds very interesting, it has to be seen if then I can access the mounted drive from any of the available backup tools... I think it is worth a try, I will keep you informed!

November 20, 2016

Hi all,

I realise my need for a backup disk for all my data, so I've been wondering lately: if I connect an internal hard drive to a SATA port (so not USB), is there a way to convince DSM not to initialize it as part of an array but keep it standalone and access it as if it were an external USB disk? This would have two reasons:

1- Since it would only serve a backup purpose, I would like to format it to NTFS, it would make things easier should I ever need to recover data;

2- since I often have Download Station running, disks never go to sleep; if one of the disks is not part of an array, it would not have DSM installed on it, so there is at least a chance for it to suspend.

What do you guys think?

Thanks!

July 6, 2016

Same reply to me, too...

Sent from my Nexus 10

June 23, 2016

Hi Trantor,

Sensors

[OK] Nuvoton nct6775

My board, AsRock N3150M, uses the NCT6792; will it be compatible with the nct6775 drivers?...

Thanks for your invaluable work!

June 12, 2016

What does parted's "align opt "n"" where n is each of the labels on the disk report? In particular does it agree that the partitions is aligned?

Er... it does not... ???

root@DiskStation:~>parted /dev/sda align opt 1

1 aligned

root@DiskStation:~>parted /dev/sda align opt 2

2 not aligned

root@DiskStation:~>parted /dev/sda align opt 5

5 not aligned

root@DiskStation:~>parted /dev/sdc align opt 1

1 aligned

root@DiskStation:~>parted /dev/sdc align opt 2

2 not aligned

root@DiskStation:~>parted /dev/sdc align opt 3

3 aligned

Ouch... I am lost again... :shock:

hdparm -I /dev/sda

reports:

Logical Sector size: 512 bytes

Physical Sector size: 4096 bytes

So my data partition on sda is in fact not aligned (not to mention the cache partition)?...

June 5, 2016

Ilciumba,

May I ask you to please repeat your parted output, (print list) for sda-f, but setting the units to bytes (units B) to eliminate rounding? That way we can divide starting sector by 4096 and at least confirm good alignment if it returns integers.

Would you also consider the output of parted's align, e.g. align opt 1, for each partition on each sample disk?

Wow, how right you were! I did as you suggested:


Model: HGST HDN724040ALE640 (scsi)
Disk /dev/hda: 4000787030016B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start        End             Size            File system     Name  Flags
1      1048576B     2551054335B     2550005760B     ext4                  raid
2      2551054336B  4698537983B     2147483648B     linux-swap(v1)        raid
5      4840079360B  4000681082879B  3995841003520B                        raid

So in fact partitions ARE 4k aligned!

1048576/4096 = 256

2551054336/4096 = 622816

4840079360/4096 = 1181660

I did not know about the "unit" option in GParted! Thank you sooo much!

But now I have yet another question: why is the first disk listed twice, once as hda and once as sda??? I see it happens to you as well...

June 3, 2016

Have you guys emailed FSF to get this thing moving?

Just done it!

June 3, 2016

Hi all, thanks for your replies.

The best way to find out if a HDD is really an "Advance Format Drive" is by checking online the model number and spec from the manufacture websites.

Absolutely agree. The datasheet for the HGST https://www.hgst.com/products/hard-drives/nas-desktop-drive-kit drives in question are silent on the topic though.

Exactly. WD EARS are indeed Advanced Format, while HGST says nothing about it, but, according to Linux, it does have 4k sectors.

Besides once the HDD becomes parts of the RAID, all the formatting goes out the window, as the RAID and format structure will be maintained by the mdadm, so the underlying physical cluster size no longer matters.

It only matters most when you try to use it for FAT32 or NTFS partitions for Windows, otherwise under linux and EXT4 partition just blankets over whatever it's underneath.

I must gently disagree. For all operating systems and disk arrangements, sector size matters.

For single disks, the minimum file system allocation unit must be a multiple of the sector size. Otherwise, misaligned allocation units will cause two sectors to be read / modified / written whenever a file system allocation unit crosses a 4k sector boundary.

I gently disagree too. Now that I think about it, when I initialized under DSM the EARS disk which is NOT reported as having 4k sectors, the file transfers were extremely slow, around 30MB/s, and I could not understand why. Now I do!

Fundamentally, make sure the start of each label / partition / volume, whatever the OS calls it is 4k aligned.

Yeah, the point is that, as I showed in my dumps in the OP, DSM system and cache partitions are not, while data partitions are. It is probably not so bad, since DSM system does not need that much speed, however the reason behind this strange behaviour puzzles me...

June 1, 2016

Nobody?... :roll:

May 30, 2016

I wrote to FSF sometime ago already, but haven't got a reply. I think more of you should also email them about violation, so they will take it more seriously I guess.

Can you please publish here what you wrote them?

May 28, 2016

Hi all,

I have recently set up my system, starting with a pair of 4TB HSGT Deskstar NAS and then adding 1 TB WD green disks.

Now I wonder if DSM is capable of correctly recognizing and aligning 4k-sector disks. I don't know if the HGST are in fact 4k-sector disks, but if I run:

cat /sys/class/block/sda/queue/physical_block_size

I get:

4096

However, if I run parted on /dev/sda and I press p I get:

Model: HGST HDN724040ALE640 (scsi)

Disk /dev/sda: 4001GB

Sector size (logical/physical): 512B/512B

Partition Table: gpt

Disk Flags:

Number Start End Size File system Name Flags

1 1049kB 2551MB 2550MB ext4 raid

2 2551MB 4699MB 2147MB linux-swap(v1) raid

5 4840MB 4001GB 3996GB raid

So apparently parted and /sys/class/block/sda/queue/physical_block_size tell two different stories. In fact, you can see that the system partitions reported by gparted are not at all aligned, while the data partition, the most important one, appears to be, but I cannot be certain since the start is given in MB and not in kB, so the rounding could trick me.

Then I have another disk, a WD WD10EARS-14Y5B1, which, following cat /sys/class/block/sda/queue/physical_block_size, reports 4096 as well, whereas parted says:

Model: WDC WD10EARS-14Y5B1 (scsi)

Disk /dev/sdd: 1000GB

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Disk Flags:

Number Start End Size Type File system Flags

1 1049kB 2551MB 2550MB primary raid

2 2551MB 4699MB 2147MB primary raid

3 4832MB 1000GB 995GB primary raid

Again, parted does not agree in the physycal sector section and system partitions are exactly as for the HGST (so not 4k aligned). However, the data partition appears to be aligned, with the same provision as before.

Curiously enough, then, I have another WD disk, this time the model is reported by parted as:

Model: WDC WD10EARS-00MVWB0 (scsi)

Disk /dev/sdc: 1000GB

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Disk Flags:

Number Start End Size Type File system Flags

1 1049kB 2551MB 2550MB primary raid

2 2551MB 4699MB 2147MB primary raid

3 4832MB 1000GB 995GB primary raid

however, this one answers 512 to the cat /sys/class/block/sda/queue/physical_block_size. Possibly it does not report the physical sector size correctly, because, to my knowledge, the EARS are 4k "advanced format" drives... Am I correct?

Being in RAID1 with the previous one, the starting point of partitions are identical.

Last disk I have is:

Model: WDC WD20EARX-00PASB0 (scsi)

Disk /dev/sdf: 2000GB

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Disk Flags:

Number Start End Size Type File system Flags

1 1049kB 2551MB 2550MB primary raid

2 2551MB 4699MB 2147MB primary raid

3 4832MB 2000GB 1996GB extended lba

5 4840MB 2000GB 1995GB logical raid

reported again as 4k by cat /sys/class/block/sda/queue/physical_block_size.

Also in this case the data partition would seem to be 4k aligned, even if I do not know why it ended up as logical partition instead of primary...???

To recap, my question is: why are system partitions not 4k aligned even if the disks report 4096 block size? Is it because it is not important that system partitions are, since they do not require speed, opposite to the data partition? Or did something go wrong during installation?

Is there a way to realign existing partitions in a non-destructive way?

Also: why the sdf has a logical partition in it?

Thanks!!!

May 16, 2016

Did You solve it?