On Sun, Sep 05, 2010 at 10:52:04AM +0200, Marcus Osdoba wrote: > Hello XFS mailinglist, > > On my armv5 device I like to use XFS for my simple home made nas, > because I think it is ideal for low/medium performance CPUs. > I searched the mailing archive about the usage of XFS on arm > architecture. I figured out, that the patchset of James Bottomley > was applied to the main line. So I expected xfs to run properly on > arm. Unfortunatly I still run into this (known) error after writing > some data on an xfs partition and remounting it: > <mailto:xfs@xxxxxxxxxxx>" > SGI XFS with ACLs, security attributes, large block/inode numbers, > no debug enabled > SGI XFS Quota Management subsystem > XFS mounting filesystem sda1 > Starting XFS recovery on filesystem: sda1 (logdev: internal) > XFS: xlog_recover_process_data: bad clientid > XFS: log mount/recovery failed: error 5 > XFS: log mount failed > " > > Am I still forced to use the "hammer" approach (flushing buffers in > xfs_buf.c) which was proposed in January 2010? Or did I misinterpret > the logfile of the xfs component in the kernel (so no arm fixing > patches were applied)? What kernel version are you running? The xfs-vipt branch was merged into mainline in late February, so kernels from 2.6.34 onwards should be OK. If it isn't ok, then we need to know exactly what ARM CPU arch you are using, and if the old brute-force cache flushing hack fix the problem or not. > Is xfs NOW be known to work on arm (e.g. armv5)? If so I like to > complain. If not, I'm willing to test patches which might solve this > issue. I don't know of any outstanding XFS specific issues on ARM, but I don't have any ARM machines here that I can test on.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
