我需要一些关于我的Linux机器上托pipe的新的1TB介质服务器的文件系统的build议。 我有一些要求：
需要共享到不同的Windows机器（不是双启动，完全不同的盒子）。 我发现至less可以select使用ext3来做到这一点，而且我认为这将是一个非常罕见的情况，我可以忍受这一点。
绝对需要能够通过我运行XBMC的Xbox上的Samba进行访问（并且可能会在未来与Xbox 360共享）。
需要允许文件大小超过4GB。
需要与我构build的任何未来的媒体服务器/前端共享（所有将运行一个Linux变种，如Boxee，XBMC，神话*）。
我猜fat32是由于文件大小的要求，而我以前使用过NTFS，我更喜欢Linux本地的东西。 我接受任何事情，谢谢。
鉴于所有从非Linux系统访问文件系统将通过抽象层，select任何你想要的！ 我会build议你的发行版的默认（可能是ext3）。 媒体存储在速度和可靠性方面没有特别的需求，所以你只需要添加一些不必要的复杂的挑剔的外来文件系统。 就你提到的具体用例而言：
我在我的MythTV服务器上使用XFS，并且工作得很好。 我也通过Samba的方式分享了某些目录，所以我的Windows工作站可以访问它。 我有一个脚本，可以将节目转码为可在我的iriver clix2上使用的格式，该格式转储到我从Windows笔记本电脑映射到的目录并传输到媒体播放器。 使用XFS作为媒体服务器的一个更好的事情是，XFS有一个碎片整理程序，因为保持这些非常大的文件顺序，毫无疑问SATA驱动器是一个好主意。
一个帮助我的build议是使用XFS的“allocsize = 256m”安装选项。 这就告诉内核在写入文件时要分配256MB的空间。 由于SD显示器在我的钻机上每小时可以以2.2GB的速度运行，这可以显着减less碎片。 我设法录制的几个高清节目大概是15GB /小时，我的文件系统并没有眨眼。 如果我运行的是64位，那么它会更less闪烁。
XFS支持在Linux领域是比较新的，但到了2.6.30这个时间已经有很长一段时间了。 我在家里或工作上没有任何腐败问题。 对于SATA驱动器上的大量随机I / O（例如加载VMWare Workstation的负载（ahem））并不太热，但是对于顺序访问而言，它会抽烟。
我正积极地在后台安装另一台媒体服务器，以补充编码器盒上的存储空间。 这也将是XFS，但通过NFS共享到MythTV盒子，以最小的networking开销。 它可能会ext4，但我还没有做任何与FS的东西呢。
XFS最适合存储video，因为它非常稳定，并且具有出色的大文件支持。 这不再是异国情调了。
与另一台计算机共享与文件系统无关。
基本上，如果你与Windows共享 – selectSamba，因为它是最简单的。
虽然Samba工作正常，但如果XBMC是您的焦点，您可能还想考虑UPNP（DLNA）。
DLNAdevise完全是为了通过networking共享媒体，对于linux来说有几种select，比如mediatomb或者ushare。
mediatomb.cc
ushare.geexbox.org
简介：将XFS用于媒体分区，将Samba或DLNA用于共享。
/ Richy
Samba应该能够与你的windows boxen和神话前端进行通信，但只要内核能够读取数据，它就不会关心数据存储在哪个文件系统上。 我会select你正在安装的发行版的默认设置。
Ext3可以明确地容纳大于4GB的文件。 如果您打算主要存储大文件，则可以设置一些调整参数以使其更高效。
对于大多数大文件的文件系统，我build议使用XFS。 它对大文件大小有很好的performance，并且非常成熟。 JFS也值得一提，并且与XFS具有相似的性能，并且已经成熟。
但是，根据您的发行版，您可能会将文件系统置于LVM之上，以便您可以无缝地扩展存储。 更进一步，我把LVM上的文件系统放在RAIDarrays上面。 这样，您可以获得容错性和性能，同时保持您的扩展能力。
直接存储的另一种select（除了Alex的NFSbuild议之外）是使用iSCSI。 我使用iSCSI Enterprise Target通过iSCSI将存储导出到我的Windows和Linux机箱。 如果没有直接访问的需求，桑巴就可以做到这一点。 不要通过NFS导入通过samba存储导入; 你将有文件locking问题。