I want to mount one machine folder to another machine on linux network.

Is there a limit on the partition size of the mount folder? I hope to give the biggest partition the linux mount can support.

Thanks

I think there is but no hard disk has been made that big yet.

Thanks.

Do you know which kernel constant is used for defining this limit?

BTW, I'm using CentOS 5.

Don't think there is one. It is the filing system you choose. Say a Fat16 has a maximum size of 2Gb I have formatted 1.5Tb disk with fat32.

If you Google "maximum partition size of Ext3" you will get this. The latest Ext4 filing system can support volumes with sizes up to 1 exabyte and files with sizes up to 16 terabytes.

Are these not big enough for you?

we really have a special machine for large disk support in production, likely more than 10TB. That's why I'm concerning this limit.

Can the mount recognize the large partition?

Look like Reiserfs is the filing system you can use according to this.

Ext4 is supported from kernel around 2.6.27 and declared stable in 2.6.28. CentOS is hanging on to 2.6.18 kernel so you may be denied the access to Ext4.

If by "the mount" you mean the mount point itself (ex. /opt). It doesn't matter what filesystem type the mount itself is in. if your "/" partition is ext3, you can have a "/external" mount point off of that, and can mount any partition type to that mount point. So, your /external can mount a Reiser file system (or a number of others), that should take care of the 10Tb problem. Unless I'm wrong, once you start reading and writing from /external, it goes by the rules of that filesystem. The filesystem of the mount point (parent directory) doesn't matter.

Also, it sounded like you will be mounting a filesystem remotely. I don't think that NFS (the normal unix/linux way to mount a remote filsystem) has any limits on the size of the actual filesystem. But if it's important to you, according to this, NFSv3 and above can now handle file sizes larger than 4Gb.

Thanks a lot.

One more question just pop up:

a 32-bit system client to a 64-bit system server mount, any problem with the disk read/write?

It really depends on the involved file system.

ext3 *does* allow 16 TiB volumes. The problem is that that's only for architectures which support it, like alpha. And in any case, if you need 8 TiB now, I don't think that limiting you to 16 is a good plan for the future.

Ext4 could do ok however I wouldn't still use it on a serious production machine without first doing my own intensive tests. I have been using it without any problem, but I am not the kind of user who thinks "if it works for me, then it works and period, and the rest of you are all wrong" It is known to have some problems for some people and in any case it's not near as mature as ext2/3.

I dislike reiserfs for many reasons, maybe that's just me though. reiser4 is different, but seeying how uncertain its future is I wouldn't even put it between the possible choices if I plan to maintain a machine for a long time. It's my view anyway, not an invitation for a discussion.

XFS has a max volume size of 16 exabytes if my memory serves correctly. This would probably be my choice for the simple reason that's the only one that remains when we discard the rest of stable fs's, BUT be sure you use a good UPS. If you can't guarantee the stability of the power source, then by all means forget about XFS.

More modern filesystems like btrfs and zfs will not have this problem either. The problem is that zfs for linux is unstable (and it's a FUSE fs anyway), and btrfs is unstable and the on-disk format can change at any random moment which is nothing you would want on a serious server. However, zfs for solaris is supposed to be stable, as for freebsd (but I haven't tried it myself). A good thing about both btrfs and zfs is that you can add a disk to the storage pool without any problem at any given momment, besides other features that are really interesting like live snapshots and many more.

If you mount it through NFS, I don't thinks there is a problem. But, I could be wrong about that. Probably someone else will have a better idea on that. But individual file sizes could be a problem if you move them between filesystems. I've never had a problem, but I don't normally deal with 10Tb systems.

File systems should remain the same, it doesn't matter the cpu or the host system even if it's local and not through network. So, there's no problem on sharing a given fs to 32 or 64 bits clients from a 32 or 64 bits server, it doesn't matter if the server is built with an entirely different architecture either.

But, even if that was an issue (which it IS NOT), when you share via network it's the network protocol which counts. As nuwen52 stated. If you mount something as NFS, CIFS or samba, that's the only thing that you can see locally. Your local system has no idea about what the underlying fs is, it might not even be a discrete disk, but maybe an array or disks or any other virtual storage facility.

Great! Thanks for you guys.

ericli,

There are two issues here. The partition table type and the file system itself.

The default MSDOS partition table can describe at most 4G of 512B sectors as it uses 32 bit descriptors.
It cannot create partitions bigger then 2TB.

For bigger partitions or to partition larger drives, you need to switch to GPT and its supporting tools. GPT uses 64 bit descriptors, so it can describe 4Gx2Tb of space. It will take drives a long time to reach that size.

With the partition table limit removed, filesystems can grow well beyond 2Tb, be careful of believing that 2Tb is the limit of any filesystem and that its not imposed by the partition size that the filesystem exists on.

Another question:

Will mount work in distributed filesystems e.g., Apache Hadoop, GlusterFS? If not, we have to switch to HTTP.

What is the advantage to use mount instead of normal HTTP? (assume all are within the firewall)