QNAP NAS Community Forum

jojje2 wrote:So I'll have to buy some TB-disks for backupping the NAS it seems, and...

Yes, take it as a sign.

You always need backup of all vital data, not only when trying to change file systems.

Sigh.. why is it that there's always someone who assumes the storage device under discussion is the only instance holding the data and feel the need to point out the importance of backup ?
In my case I use the NAS as *the* backup. The managed data resides on other systems.

Perhaps it was my phrasing in this instance. I probably should have used the phrase "So I'll have to buy some TB-disks for temporarily moving the data over to during the disk replacement, in order to minimize downtime".

Anyway, as you seem very keen on my backup data well being, I now have "data center redundancy" in place for my "home stuff". 2 x TS 439 in two different geographical locations with nightly rsync between them, in case of a disaster, natural or otherwise. Has worked beautifully. Though I woe the day the master device breaks and I have to sync 5TB back over a measly 10MBit line
I'll probably have to do the synching on-site, at the backup site with a twisted CAT-cable to get 1Gbit speed, or do disk-by-disk cloning at SATA speed. Else restore will take forever (2 months).

jojje2 wrote:Sigh.. why is it that there's always someone who assumes the storage device under discussion is the only instance holding the data and feel the need to point out the importance of backup ?

Maybe because that's the reality for a majority in this community? At least that's what I believe when I daily see users weeping here about how they "lost the data that they trusted to the NAS".

Since this a public forum and not a personal conversation, maybe even somebody else read my comment and was helped by it? Anyway, since you were obviously so disturbed by my comment I'm very sorry for it.

Just wanted to say that the procedure has worked perfectly for me on my TS-509!

It might help others to note that a "/etc/init.d/services.sh stop" is sufficient to stop everything that might interfere with the conversion.

In addition, after the conversion (and installing e2fsprogs through ipkg) a "chattr -RV +e /share/MD0_DATA" will ensure that all files in fact are using extents and don't remain in ext3-compatibility-mode.

EDIT: It appears that converting a 4 year old ext3 filesystem to ext4 really doesn't yield the best results. For one thing, the fragmentation remained so high that performance was still really bad. In addition, the inode size remained at 128, where ext4 should actually have 256 for all the new features. All in all, I decided to back up the entire thing to an external harddisk and reformat to "real" ext4. Now the performance is great and I hope that the ext4 extents will keep it this way.

I ran into an issue of EXT3 on my TS-419p version 4.3.3.0663. The issue is related to the number of subfolders a folder can have; EXT3 is limited to basically 32K. (See this article https://blog.nexcess.net/2012/04/27/mkd ... ow-to-fix/). I need a much larger number of subfolders, i.e. 40K. I believe EXT4 supports 64K subfolders in a folder.

So if I use this upgrade procedure as stated in this [HOWTO} discussion, is the limitation of 32K be extended to 64K subfolders? If this method does not, I will just have to backup the data and reformat the drive to EXT4.

better make sure that you have recent backups at all times .. even more so if you want to go through with this 9 year(!!) old procedure (don't necorpost next time and rather open a new thread) for a different device class than yours (CAT1 x86 vs CAT1 ARM)