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

bomaroast wrote:

What exactly is the "hiddin way" of formatting using ext3?

WARNING:  BACK UP YOUR DATA BEFORE PROCEEDING  :WARNING

DOING THESE STEPS ON A DNS-323 RUNNING FIRMWARE < 1.03 HAS PROVEN TO VERY EASILY CAUSE DIRECTORY AND/OR FILE CORRUPTION ON THE EXT3 MOUNTED FILE SYSTEMS!!!!

Bomaroast,
There is more than one way to go about migrating to EXT3.  It also depends on the disk configuration and which mount point is to be EXT3.  The way I have been doing it has been with telnet and utility access via the busybox3 and usb-storage.ko found elsewhere on the wiki.  You can convert the current EXT2 file systems to EXT3 or reformat to EXT3.  I prefer converting the FS so I don't have to backup and restore the .systemfile tree and converting the FS does not erase the data.  (as always, BACK YOUR DATA UP FIRST!!!)


I have my fun_plug script set up to copy the usb-storage.ko to /tmp and then run "insmod /tmp/usb-storage.ko".  This installs the USB support into memory so the file systems are not prevented from unmounting by the USB support.  After that, the fun_plug mounts a USB thumb drive to /mnt/ext and starts telnet from the thumb drive.  Again, this is to allow the file systems on the hard drives to be unmounted (not busy) and does not waste memory for the busybox3 utilities.  I found that a 10 second delay was necissary after loading the usb-storage library for it to be fully available for mounting.  See below:

  #
  # fun_plug
  #
  DIR=/mnt/HD_a2
  dmesg > $DIR/dmesg.boot
  cp $DIR/lnx_bin/usb-storage.ko /tmp
  insmod /tmp/usb-storage.ko
  sleep 10
  mkdir /mnt/ext
  mount -t ext3 /dev/sdc1 /mnt/ext
  /mnt/ext/starttelnet.sh

My busybox3 lives in /mnt/ext/lnx_bin and has symbolic links to it for e2fsck, fdisk, fsck.ext3 mkfs.ext3, tune2fs, umount, etc....

Now telnet in and execute "mount" and look for the /dev mounts.

  %root% on / type unknown (rw)
  proc on /proc type proc (rw)
  /image.cfs on /sys/crfs type cramfs (rw,loop=/dev/loop0)
  /dev/md0 on /mnt/HD_a2 type ext2 (rw,usrquota,grpquota)
  /dev/sda4 on /mnt/HD_a4 type ext2 (rw)
  /dev/sdb4 on /mnt/HD_b4 type ext2 (rw)
  none on /proc/bus/usb type usbfs (rw)
  /dev/sdc1 on /mnt/ext type ext3 (rw)

Look at the /mnt/HD_## mounts.  If you are using RAID 0 or 1 as the above example shows, you will be working with /dev/md0.  If you are using Individual disks or the "hidden" partitions, it will be /dev/sda# or /dev/sdb#.

Next you need to make sure the DNS is quiet.  Shut off all the services that could lock the file systems from being unmounted.  (ie UPnP, FTP, iTunes, etc...)  Unmount the FS.

"umount /dev/md0"

Convert the FS to EXT3

"tune2fs -j /dev/md0"

  tune2fs 1.38 (30-Jun-2005)
  Creating journal (8192 blocks): done
  This filesystem will be automatically checked every 23 mounts or
  180 days, whichever comes first.  Use tune2fs -c or -i to override.


If this FS if for one of the Volume_# exports, the DNS config files must be updated to mount the FS as EXT3.  By default they will still mount the Volume_# EXT3 FS as EXT2.  The hidden partitions are mounted in their native format.  Use the find command to find all the copies:

"find / -name raidtab2web"

  /etc/raidtab2web
  /etc/tmp_raid_table/raidtab2web      <--   ignore this one
  /mnt/HD_a4/.systemfile/raidtab2web
  /mnt/HD_b4/.systemfile/raidtab2web

edit the /etc/raidtab2web and the /mnt/HD_##/.systemfile/raidtab2web files and change the EXT2 to EXT3.

Now reboot your DNS and telnet in make sure everything is mounted right:

"mount"

  %root% on / type unknown (rw)
  proc on /proc type proc (rw)
  /image.cfs on /sys/crfs type cramfs (rw,loop=/dev/loop0)
  /dev/md0 on /mnt/HD_a2 type ext3 (rw,usrquota,grpquota)
  /dev/sda4 on /mnt/HD_a4 type ext2 (rw)
  /dev/sdb4 on /mnt/HD_b4 type ext2 (rw)
  none on /proc/bus/usb type usbfs (rw)
  /dev/sdc1 on /mnt/ext type ext3 (rw)


Note:  Every time you access the Web interface, you will get a nasty-gram saying you need to convert the filesystem from EXT3 to EXT2.  Clicking [OK] will take you to the standard logon screen.


Cheers!
bspvette

Marinalink,
Running "uname -a" on firmware 1.05 returns:
Linux Media1 2.6.12.6-arm1 #29 Wed Apr 30 10:03:59 CST 2008 armv5tejl unknown

I'll have to reboot my box a few times to check on the auto mount check....   Haven't had one version of the firmware on there for more than a couple of days lately...

I completely understand not wanting to use EXT3 until official support comes.  I'm providing this information:
  a) in case someone on the inside at Dlink is watching, with hopes that they will consider doing some in house EXT3 tests of there own and bring native support back.
  b) For those of us hacks that are interested in using EXT3 now but haven't had time or thought to do any tests with the newer firmware. 

Please remember that virtually nothing on this site is supported or in any way recommended by the manufacturer. 

Cheers!
bspvette

Last edited by bspvette86 (2008-05-30 23:38:23)

Is there an easier way to format the partition(s) to ext3 without following the steps listed above, bspvette86 or others? I do not care if I wipe the data clean off the drives. I just got my first 323 today and so far am loving it. I did upgrade the firmware to 1.05, and installed fun_plug 0.4 if that matters. Thanks in advance.

marinalink wrote:

Do you have any new results from your tests with EXT3?

Marinalink,
So far I have yet to find any problems with EXT3 on 1.03 and above.  I did a few perfomance tests comparing the different drive and EXT configs available using the Quickie NAS tester found here in another thread.  In all cases (standard, jbod, Raid-0, and Raid-1) EXT3 had a slight performance impact  (don't have the results with me at the moment to give the %).   I have had my box in a 1.05 Raid-0 EXT3 config since last friday.  I have put my standard media collection back on (roughtly 600GB at the moment) and have been using it lightly compared to the previous weeks testing.  I've been busy around the house and yard so testing has not been high on my list this week.

Regards,
bspvette

Couple of thoughts and questions:
1. First, I don't think you need to edit the /etc/raidtab2web file since it is on ramdisk and gets recreated anyway each time (presumably from mnt/HD_a4/.systemfile/raidtab2web and /mnt/HD_b4/.systemfile/raidtab2web

2. What would happen if you didn't edit *ANY* of the raidtab2web files?

3. Is there any reason not to similary change /mnt/HD_a4 and /mnt/HD_b4 to ext3?
    Since they are not RAID, presumably all you need to do is tune2fs and no need to change raditab2web or any other file

4. Has the ext3 implementation continued to be stable for you all these months?

5. Finally, I would think that anybody using fun_plog or other mods should definitely consider changing to EXT3 due to the better stability in the face of the  (almost) inevitable unclean power-down or reboot.

Thanks.
With regards to #1, I still maintain that the file /etc/raidtab2web doesn't need to be edited since it is stored in volatile memory anyway. It seems that on reboot, it is read from the hd_a4/hd_b4 versions.

Note I never touched that file and it still has EXT3 (not EXT2) in the file system field

good - then we are in total agreement

The performance with ext3 will degrade because of the extra processing required to create the journals and the time required to write them to disk.

Caio,
It really depends on your I/O.  If you are not doing many writes, the performance is negligable.  With many writes, the performance hit could be significant.

Regards,
bspvette86

I'm having some issues trying the umount /dev/md0 - it keeps saying the drive is busy.  I shut down all the services from the web configuration.  Is it because I'm logged in through ssh using ffp?

Warning - Ext3 may not be as stable as it seems even with 1.05.
At least when used with kernel nfsd, one repeatedly gets large numbers of randomly dropped directories and files. (see http://dns323.kood.org/forum/viewtopic. … 630#p22630 for details).

Given the critical importance of having a rock-solid and reliable file system, I would suggest that unless you know what you are doing, the risks of using EXT3 and corrupting your data outweigh the benefits of journalling. YMMV.

puterboy wrote:

Warning - Ext3 may not be as stable as it seems even with 1.05.
At least when used with kernel nfsd, one repeatedly gets large numbers of randomly dropped directories and files. (see http://dns323.kood.org/forum/viewtopic. … 630#p22630 for details).

Given the critical importance of having a rock-solid and reliable file system, I would suggest that unless you know what you are doing, the risks of using EXT3 and corrupting your data outweigh the benefits of journalling. YMMV.

Given the fact that you first reported this "randomly dropping files" as occuring with nsfd - should you not attempt to isolate the problem to one or the other?

my understanding is kernel is unchanged