On Mon, Mar 22, 2021 at 05:50:55PM +0100, Ralf Groß wrote: > No advice or rule of thumb regarding needed memory for xfs_repair? People are busy, and you posted on a weekend. Have some patience, please. > Am Sa., 20. März 2021 um 19:01 Uhr schrieb Ralf Groß <ralf.gross+xfs@xxxxxxxxx>: > > > > Hi, > > > > I plan to deploy a couple of Linux (RHEL 8.x) server as Veeam backup > > repositories. Base for this might be high density server with 58 x > > 16TB disks, 2x RAID 60, each with its own raid controller and 28 > > disks. So each RAID 6 has 14 disks, + 2 globale spare. > > > > I wonder what memory requirement such a server would have, is there > > any special requirement regarding reflinks? I remember that xfs_repair > > has been a problem in the past, but my experience with this is from 10 > > years ago. Currently I plan to use 192GB RAM, this would be perfect as > > it utilizes 6 memory channels and 16GB DIMMs are not so expensive. Filesystem capacity doesn't massively affect repair memory usage these days. The amount of metadata and the type of it certainly does, though. I recently saw a 14TB filesystem require 240GB of RAM to repair because, as a hardlink based backup farm, it had hundreds of millions of directories, inodes and hardlinks in it. Resolving all those directories and hardlinks took 3 weeks and 240GB of RAM.... I've seen other broken backup server filesystems of similar size that have had close on 500GB of metadata in them, and repair needs to index and cross-reference all that metadata. Hence memory demands can be massive, even in today's terms.... Unfortunately, I haven't seen a broken filesystem containing extensive production use of reflink at that scale, so I can't really say what difference that will make to memory usage at this point in time. So there's no one answer - the amount of RAM xfs_repair might need largely depends on what you are storing in the filesystem. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
