From: CAREY SCHUG via talk <talk@gtalug.org>

Note: several Microsoft patents "read" on exFAT. They even sued one populare GPS manufacturer to death for unauthorized use of those patents.

Preview question: NB, I am considering some flavor of Solaris for my future fileserver, so the ability to read and if possible write (for backups) from there is a requirement.

OpenSolaris was abandoned long ago. Regular Solaris is expensive to acquire, unless you got a license with old hardware. Such old hardware is probably a bad choice for a server unless you like the novelty. Even with a license, support is expensive. I think that a support contract is the only way to get security patches. If by "Solaris" you mean some fork of Open Solaris, that's quite possible. I think that they are all downstream of OpenIndiana. My impression of that community is that they are having trouble keeping up. My guess is that you are attracked by maintained forks of Open ZFS. Subsequent developments of ZFS by Sun were not made available to Open ZFS. Although ZFS was original designed for Solaris, the open source successors "home" OS became a *BSD. Now, upstream is actually Linux!

subsequent queries specifically for writing seemed to confuse solaris with linux....

AI Overview … Yes, Solaris can read exFAT and NTFS file systems:

It probably wasn't in Open Solaris. You probably cannot make a blanket statement about all Solaris variants and versions.

------------------------------------------------------

Two questions, partition table (1) and filesystem (2)

1. When I first looked, I only saw GPT vs MBR partition tables, now I found many: https://unix.stackexchange.com/questions/289389/what-are-the-differences-bet...

The options correspond to the various partitioning systems supported in libparted http://www.gnu.org/software/parted/; there's not much documentation https://www.gnu.org/software/parted/manual/html_node/mklabel.html#mklabel, but looking at the source code http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/labels: * o aix provides support for the volumes used in IBM’s AIX (which introduced what we now know as LVM); o amiga provides support for the Amiga’s RDB partitioning scheme; o bsd provides support for BSD disk labels; o dvh provides support for SGI disk volume headers; o gpt provides support for GUID partition tables; o mac provides support for old (pre-GPT) Apple partition tables; o msdos provides support for DOS-style MBR partition tables; o pc98 provides support for PC-98 http://people.freebsd.org/~kato/pc98.html partition tables; o sun provides support for Sun’s partitioning scheme; o loop provides support for raw disk access (loopback-style) — I’m not sure about the uses for this one. As you can see, the majority of these are for older systems, and you probably won’t need to create a partition table of any type other than gpt or msdos.

There are few reasons to create msdos partitions these days. - running a quite old OS - fear of the third milenium.

For a new disk, I recommend gpt: it allows more partitions, it can be booted even in pre-UEFI systems (using grub), and supports disks larger than 2 TiB (up to 8 ZiB for 512-byte sector disks).

Since these are 4 TB disks, gpt it is?.

I think that MBR works with 4 TB hard drives because the blocksize will be 4k, not 512. I no longer remember all the hacks for handling large sized drives on older systems. There were a lot of them!

Unrelated bonus question: i had thought sun WAS the same as gpt, are they close to being the same? I remember that sun put a fingerprint on raid drives, physically move them around and it would recognize them wherever they appeared, and if one re-appeared was automatically resynced, is that unique to sun, or is that a unix programming function?

Every modern system fingerprints things with (at least) UUIDs. Except older MSDOS. (Anecdote: this was one way that Atari ST's TOS disks were different from MSDOS disks. Circa 1985.) Sun, back in my day (up until about 1994) didn't use GPT. They used a BSD-style partitioning scheme, I think.

2. what filesystem? am I confused, is exfat older than ntfs?

FAT dates back to the filesystem create for 86-DOS by Seattle Computer Products (PCDOS / MSDOS was derived from that). It was a little different from the CP/M filesystem. There have been a million variants since then. FAT is older than NTFS. Some FAT variants, such as exFAT, are newer.

AI Overview Learn more … NTFS and exFAT are both file systems with different characteristics, including: Compatibility NTFS is only read-only on a Mac, while exFAT has read/write compatibility with macOS. ExFAT is also more broadly compatible than NTFS, and works with all versions of Windows and modern versions of macOS. File size exFAT has a maximum file size of 128 petabytes, while NTFS is designed to perform well on very large hard disks. Features NTFS includes features like access control lists (ACLs), filesystem encryption, transparent compression, and volume shadow copy. exFAT lacks some of the newer features of NTFS, like journaling and encryption. Speed When using an external drive system, exFAT may be the faster option than NTFS. Use cases NTFS is better for internal drive file systems, while exFAT is better for external drives and storing and writing larger files on multiple devices. Storage devices exFAT is optimized for flash drives, and is the default file system for SDXC and SDUC cards larger than 32 GB. so, exFAT? I think I used NTFS in the past when I wanted to share a partition between windows and linux (for a dual boot system). While I don't expect to ever need access from IOS, it might be better for that reason too. Not FAT32 because of a file size limit of 4 GB, potentially smaller than a DVD image.

DVD's have their own filesystems.

do either or both retain the linux read/write/execute permissions, even partially (since ownership is hard to maintain across systems)? or some other filesystem that fulfills my other requirements?

There are details that matter. For example, filesystems with file "owners", make exchanging files a little more difficult. *FAT* does not record owners.