2TB disk. Problems?

[oooyeah]

Hi,
My Network Space v1 got fucked up in a power outage. So now I'm wondering if you can put any 2TB disk in the NSvs1?

I've got a Western Digital Caviar Green WD20EARS 2TB laying around so I'm planing to use that. But I think that there are some problems using that disk with linux. Anyone got some experience using 2TB disks?

[Jocko]

Is what makes you think there will be a problem with linux?
In principle Linux accepts partitions up to 2TB without difficulty.

Fvdw can you confirm this (I have not tried with that partition size)

[oooyeah]

Is what makes you think there will be a problem with linux?
In principle Linux accepts partitions up to 2TB without difficulty.

Fvdw can you confirm this (I have not tried with that partition size)

I have read that this might be a problem: http://wdc.custhelp.com/app/answers/detail/a_id/5357
and that the 4k-sector size vs 512byte-sector size can cause problems with some OS's. This might only be a problem for Windows (32-bit) and not Linux, I don't know.

[fvdw]

We use ext3 format for the data partition and 2 TB should be no problem with 4k blocks

see for example here http://en.wikipedia.org/wiki/Ext3

also the power saving should be no problem, typycially spin down is after 15 minutes of inactivity

[oooyeah]

We use ext3 format for the data partition and 2 TB should be no problem with 4k blocks

see for example here http://en.wikipedia.org/wiki/Ext3

also the power saving should be no problem, typycially spin down is after 15 minutes of inactivity

Awsome! Hopefully I can get access to a stationary PC this week, only have laptops at home, and have a go at installing the firmware using the "script method" on my WD HDD.

I will post a success/failure notice as soon as I can. Thank for the quick response!

[Orka Borka]

I'm using right now a Lacie Network Space v1 with a Western Digital 2TB Black Caviar and firmware 1.2.9.fw fvdw-sl 8.0. No problems so far.

Well, except being unable to read the original XFS 1tb partition from the hitachi disk shipped with the unit using some adaptors.. It seems that some sata to ubs controllers have problems identifying the right disk size when formatted as XFS (EXT2 partitions are perfectly working.)

[fvdw]

To use in the fvdw-sl firmware the xfs file system a kernel module need to be loaded, its not loaded standard as it it consumes quite some memory and as it is not very common used on usb disks.
The kernel module is included in the firmware, manual loading can be done using putty.

Code: Select all

insmod /boot/xfs.ko


Also the auto mount function will not recognize it as the type 'xfs' is not defined in the function.
That means no share will be created when you connect the disk and the disk will not be mounted.
To see if the system recognized it you could type in putty

Code: Select all

fdisk -l


If it is recognized it will be listed in the output (of course first the kernel module must be loaded), you also will see then which /dev it uses

If it is recognized by fdisk you can mount it manually, but you might encounter memory issues

If you try it let us know if it works so we can include it as an option in the firmware

[Orka Borka]

Unfortunately it seems that I cannot mount the original XFS partition from the original 1GB hitachi driver while using the Network space front usb port.

here's the output from fdisk -l (I've already loaded xfs.ko and dmesg confirmed with the message "SGI XFS with security attributes, large block/inode numbers, no debug enabled
" )

Code: Select all

Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks  Id System
/dev/sda1               1          32      257008+ 83 Linux
/dev/sda2              33          64      257040  83 Linux
/dev/sda3              65          96      257040  82 Linux swap
/dev/sda4              97      243201  1952740912+  5 Extended
/dev/sda5              97         144      385528+ 83 Linux
/dev/sda6             145         145        8001  83 Linux
/dev/sda7             146         178      265041  83 Linux
/dev/sda8             179      243201  1952082216  83 Linux

Disk /dev/sdb: 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/sdb1               1         125     1004031   5 Extended
/dev/sdb2             126      121601   975755970  83 Linux
/dev/sdb5               1          16      128457  82 Linux swap
/dev/sdb6              17          17        8001  83 Linux
/dev/sdb7              18          18        8001  83 Linux
/dev/sdb8              19          40      176683+ 83 Linux
/dev/sdb9              41         124      674698+ 83 Linux
/dev/sdb10            125         125        8001  83 Linux



The partition is correctly recognized using the same USB-to-Sata Adapter on Ubuntu 11.04, while it gets ignored on both while using a different adapter.

here's the output from lsusb -vvvvv : http://pastebin.com/LswCAWey

Unfortunately I need to format the original 1TB drive, do you need any other log/debug info before I delete the original partitions?

[fvdw]

which mount command did you try ?

(I assume you use putty command line and ssh access and that sdb2 is the xfs partition)

first create a mount point for example /mnt/xfs

mkdir /mnt/sdb2

then use the the mount command

mount /dev/sdb2 /mnt/sdb2

It should out detect the file system
if not you could try

mount -t xfs /dev/sdb2 /mnt/sdb2

If mount succeds typing "mount" will give info on mounted file systems, also dmesg should give some info if it fails to mount

[fvdw]

ps as the original lacie kernel was able to use xfs partition the memory and cpu should be capable to mount and handle xfs file system
I checked the output of the original kernel (posted on the internet) and it seems to loaded the xfs with same comment as you mentioned in the output of dmesg