DSM-G600, DNS-3xx and NSA-220 Hack Forum

Hello,

I've been playing around with my CH3SNAS for a couple of weeks and I would like to ask some questions and throw some suggestions in just in case someone finds them useful.

My actual configuration is:

CH3SNAS • 2x Seagate Barracuda ES 7200.11 ST31000340AS 1TB SATAII (3.0Gb/s) 7200RPM 32MB • RAID1 • FW1.04RC6 (0822-rc6) • ext2

1. Filesystem

1.1 Ext2 or Ext3?
Right now I'm using ext2 but I don't know if converting the filesystem to ext3 would add any benefits. Ext3 does support journaling, but at the same time it has less performance than ext2. On the other hand, filesystem checks on ext3 are faster than on ext2. I'd say that ext2 is for performance and ext3 is for stability/added data security.

It's possible to tweak the ext3 filesystem to gain some performance (losing some data security) by using Journal Data Writeback method instead of the default Journal Data Ordered method. Another trick is to set the journal commit time to higher values, by default journal is commited to disk every 5 seconds. Setting it to very large values will improve performance.

Finally, both ext2 and ext3 performance can be improved by using the "nodiratime" and "noatime" switches at mount time. If you don't need to store the last access time for every single file or directory that is used, you can just turn it off.

So, as a summary:
If using ext2, you can gain a little performance by adding "nodiratime,noatime" to your fstab (or mount options).
If using ext3, you can gain a noticeable performance by adding "nodiratime,noatime,data=writeback,commit=600" to your fstab (or mount options).

I think the filesystem mounting process is done in /etc/hotplug/satamount , so the change should be done at lines 175 and 180:

/bin/mount -t ext3 -o nodiratime,noatime,data=writeback,commit=600,"$Quota" ...
[...]
/bin/mount -t ext2 -o nodiratime,noatime,"$Quota" ...

1.2 Wasted space
Disk space is wasted at several levels on the CH3SNAS:

- The swap partitions are *big*. With my configuration, I get 2 512MB partitions, one on each drive. That's 1GB of swap memory.
- The "data" partitions (sda4 and sdb4) are also way too big. Like 512MB each, and I've seen no more than 69/32 blocks used. I don't know if more space is used from time to time (to store big print tasks, as tmp space for uPNP streaming,...?), but at first look it seems like this space is totally wasted:

# df|egrep '(sda4|sdb4)'
/dev/sda4               497861        69    497792   0% /mnt/HD_a4
/dev/sdb4               497861        32    497829   0% /mnt/HD_b4

- According to fdisk, sda2 (and sdb2) have 974133405 blocks:

# fdisk -l /dev/sda

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sda1               1          66      530113+ 82 Linux swap
/dev/sda2             131      121404   974133405  83 Linux
/dev/sda4              67         130      514080  83 Linux

Partition table entries are not in disk order

But df shows a totally different value:

# df|grep md0
/dev/md0             958846504    160108 958686396   0% /mnt/HD_a2

That's 974133405 - 958846504 = 15286901 "lost" blocks (15GB!). This space is usually reserved when the filesystem is made to store superblock copies and inode entries. As I'm using ext2, there's no reserved space for journaling. The "Reserved block count" is also 0.

Regarding the swap partitions, 256MB or 512MB should be enough (though I don't mind having 1GB). What's even worse it's that the swap partitions priority is not really optimal:

# cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/sda1                               partition       530104  0       -1
/dev/sdb1                               partition       530104  0       -2

On RAID systems where the swap is distributed between different drives, the priority of the swap partitions should be set to 0 (for all of them). Swap is activated in /etc/rc.sh by running /usr/bin/judge_swap:

# strings /usr/bin/judge_swap|grep swapon
swapon /dev/sda1
swapon /dev/sdb1

We can improve this by either adding this to the top of /etc/fstab:

/dev/sda1        swap             swap        defaults,pri=0         0   0
/dev/sdb1        swap             swap        defaults,pri=0         0   0

Or changing judge_swap's way to use swapon:

swapon -p 0 /dev/sda1
swapon -p 0 /dev/sdb1

Regarding the "lost space" after making the filesystem, according to tune2fs, /dev/md0's inode count is 121782272. Each inode takes 128 bytes, that's 15588130816 bytes (or 15222784KB -or "blocks"-). Voilá! almost all the "lost" space that we previously saw.

If you're planning on storing less than 121782272 files/directories, you can definitely regain some space by lowering the number of inodes reserved by the filesystem. It all depends on which kind of files you're going to store: if lots of small files, documents, pictures, mp3 files... You'll want a high inode value. If you're storing media files, you definitely will need less inodes. For example, if you set the reserved inode count to 1 million at mke2fs time, you'll only use 128MB instead of using 15GB. To achieve this, "largefile4" can be added to te filesystem features at mke2fs time (as an intermediate solution) or specify the exact amount of inodes you want with "-N number-of-inodes". The other filesystem features set by default (dir_index filetype sparse_super) are nice (specially dir_index for performance and sparse_super to save some space).

I really don't know what should be done with the /dev/sda4 and /dev/sdb4 partitions. It looks like they could be a lot smaller, but as I said, I don't know if it's used to store large amount of data at sporadic times.


2. General system issues

2.1 Spindown disks or not?
I had the default value for the spindown (power saving) setting of the CH3SNAS but I encountered two problems. First of all, when the disks are idle it takes a while until they are 100% functional again. I also don't know what's better, if having the disks always spinning, or the constantly spindown-spinup-spindown-spinup when using the power saving feature. I feel that the drives (specially the mechanic parts) might suffer more if they have to stop and start lots of times instead of having them always running. Secondly, I tried to run an extended SMART test to the disks, but it was aborted by the host as the drive went idle after some minutes. Since the extended SMART test can take up to four hours and the CH3SNAS is set to spindown the disks after a few minutes, there's no way of performing those tests, which I run periodically to control the health of the drives.

2.2 /dev/mtdblock0 is always mounted - is that ok?
On my system, /dev/mtdblock0 is always mounted on /sys/mtd1 . It's not a problem for me but I think I read somewhere in this forum that it might be a symptom of a problem. I'd appreciate if someone could confirm (or deny that).


Overall, the CH3SNAS system is very interesting, specially after installing fun_plug. I might buy a 1TB external hard disk to make regular backups of it (I know, I know, "RAID is for redundancy, not backup") using the USB connector and a rsync script, because I'm not self confindent about the CH3SNAS reliability regarding the RAID implementation, or the problems that can appear when upgrading the firmware. But I'm really enjoying playing around with the box.