On Tue, Oct 26, 2004 at 12:05:30PM +0200, Frank Hellmann wrote:
> Similar effects here. Basically we have the same setup (Hardware RAID5
> with Software RAID0 striped together). I ran into some problems during a
> xfs_repair. See these articles:
>
> http://marc.theaimsgroup.com/?l=linux-xfs&m=109714077512194&w=2
>
> http://marc.theaimsgroup.com/?l=linux-xfs&m=109719162327429&w=2
>
> Not to good news, I am afraid. We are currently working on a scheme to
> cache our files into multiple directories instead of the filesystem
> root. That as far as I can tell helps to avoid this issue. So you
> shouldn't run into these during xfs_repair.
>
> Concering xfs_check... anyone?
Well, I am even more confused now. I got "attracted" to XFS by reading a
comparison between XFS and EXT3 which stated that EXT3 on a huge
partition is a memory and time hog. Indeed, I have several hardware RAID
arrays sliced into sub-2TB partitions with EXT3 FS, and it takes a few
hours to complete a filesystem check after a crash. Well, but it
completes. Now the XFS, advertized as a true 64-bit FS, capable of
dealing with Petabytes, seems to be unable to check an almost empty
partition and/or repair a partition with several hundred thousand files.
On the other hand, I've read a page "Who's using XFS" with some
important projects (like Sloan Digital Sky Survey) generating huge
amounts of data. Do they also have partitions that they cannot check/repair?
The oss.sgi.com/projects/xfs pages content suggests that actually 'fcsk'
is not needed anymore on a journalling FS like XFS. So maybe we can just
live without it?
To resume, could someone tell me whether I can safely put my data on a
3.6TB XFS filesystem or not? The machine it is currently attached to
has 4GB RAM + 2GB Swap. If this is not enough for XFS to do a
check/repair, I would say it is not a solution for me.
regards, Michal.
PS. I've just found, on http://oss.sgi.com/projects/xfs/irix-linux.html
> Linux XFS filesystems are limited to 2 Terabytes in size due to
> limitations in the Linux block device I/O layers.
Is it just an out-of-date page? Or, maybe, it is just the true reason of
our problems?
--
Michal Szymanski (msz at astrouw dot edu dot pl)
Warsaw University Observatory, Warszawa, POLAND
|