I not longer want this as network attached. The USB share is limited to several hundred gigabytes. I want to change it to an ext3 file system (or anything really) and increase it to a full 2 TB.

I thought it would be easy enough to create a new virtual file image / loop device,... format it, amend fstab and voila! However I can't make sense of how the NAS mounts drives.

There's no mention of most of the mounts in fstab,... but when I run 'mount' they all show up.

Any assistance would be greatly appreciated.

For some reason the nas lists the same dev listed against multiple mount points. This I don't understand. I also don't know where the system decides to mount the loop devices (or any of the other shares) since they're not in fstab.

Looks like it's pretty much a ghost town around here, but still you're this NAS's only hope before it joins the scrap pile.

Probably also worth mentioning that I unmounted all my shares via root whilst attempting to figure out what was going on....now I can't get them back. I can probably reset the drive, but I'd prefer not to.

The USB share is a single big file on the data partition, which is loop mounted to provide the 'USB-share'. As soon as you connect the USB plug, the OS umounts the loop mount, and serves the file as an USB disk. (The +5V on the USB bus is causing the switch, not the data lines)

So you only need to put an ext3 filesystem on the USB-share, using the USB entry, to get it ext3.

If you simply don't want that share, you'll have to factory reset the box. Then you can assign 0 bytes to the USB share. Maybe it's enough to delete and re-create the volume.

Quote:

There's no mention of most of the mounts in fstab,... but when I run 'mount' they all show up.

That's normal on an embedded Linux system like a NAS. As you can create and delete shares using the web interface, the box needs a backend with sufficient rights anyway. So it's easier to let that daemon mount the shares than populating fstab.

Quote:

I unmounted all my shares via root whilst attempting to figure out what was going on....now I can't get them back.

I wondered what process mounts the data partition at boot time if it's not in fstab.

By the way, I don't want to simply get rid of the USB share. I want to change to max size beyond the limit imposed by a FAT file system. I already think I know how to create a disk image, and how to mount it via fstab,... But it doesn't look like the NAS mounts drives this way.

I wondered what process mounts the data partition at boot time if it's not in fstab.

Unicorn, probably.

Quote:

By the way, I don't want to simply get rid of the USB share. I want to change to max size beyond the limit imposed by a FAT file system.

Bigger than 2TiB? Anyway, it doesn't matter. You can put any filesystem you want on that share, and even create several partitions, as long as you do it using the USB connection.If you use a too exotic filesystem you won't have an USB-share anymore, as the NAS will fail in loopmounting it.When I remember well it will also only serve the 1st partition. There is some logic which reads the partition table, and outputs the offset of the first partition. This offset is used for the loop mount.

I think so, but I don't know how to bypass it. In the past I have tried to just grow or shrink that single big file, but that didn't do the trick. So I guess Unicorn has somewhere in it's database the 'real' size if the file, and simply rejects it when it has the wrong size.If you can find the code of that webpage, maybe you can change the max before dragging the slider. Maybe that's even possible at client side.

About the restrictions of FAT, FAT32 uses 28 bits to describe a cluster number. The biggest clustersize used in FAT is 64kB, (although Windows NT3.51 supported 128kB clusters, to bypass the 2GiB limit before FAT32 existed) so theoretically a FAT32 volume can be 16TiB. There is a catch, the header of a FAT32 volume has a 32 bits field which mentions the 'big total number of sectors', which limits the volume to 2TiB. AFAIK that field is unnecessary, as it's redundant. Don't know if an OS actually reads it. If not, 16TiB is the limit, unless you use out-of-spec clustersizes.

Having said that, a FAT volume of 16TiB is a bad idea™ . The filesystem is simply not robust enough. Running chkdsk on a 16TiB volume will take days, if it doesn't die on lack of memory. Further it will be slow. The FAT table itself is 1GiB, which doesn't fit in the cache. So the disk will constantly be re-positioning it's heads.

Who is online

Users browsing this forum: No registered users and 10 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum