Re: Speeding up xfs_repair on filesystem with millions of inodes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dave!
Everything is in good shape again. This time xfs_repair finished without
detecting any problems. So i suppose the only problem was that there
wasn't enough RAM.
---snip---
        XFS_REPAIR Summary    Wed Oct 28 15:02:30 2015

Phase           Start           End             Duration
Phase 1:        10/27 23:19:34  10/27 23:19:34
Phase 2:        10/27 23:19:34  10/27 23:19:57  23 seconds
Phase 3:        10/27 23:19:57  10/28 04:10:50  4 hours, 50 minutes, 53
seconds
Phase 4:        10/28 04:10:50  10/28 09:03:00  4 hours, 52 minutes, 10
seconds
Phase 5:        10/28 09:03:00  10/28 09:03:16  16 seconds
Phase 6:        10/28 09:03:16  10/28 15:02:29  5 hours, 59 minutes, 13
seconds
Phase 7:        10/28 15:02:29  10/28 15:02:29

Total run time: 15 hours, 42 minutes, 55 seconds
---snip---

On 28.10.2015 01:17, Dave Chinner wrote:
> 
> Maybe you have a disk that is dying. Do your drives have TLER
> enabled on them?
>
Thanks for the hint. These are all enterprise-grade Nearline-SAS drives
(SEAGATE ST32000444SS) attached to a Dell PERC 6/i controller. I think
it isn't even possible to turn TLER on or off on them. They should all
be in good shape since the controller automatically does periodic patrol
reads.

On 28.10.2015 01:17, Dave Chinner wrote:
> 
> If kswapd is doing all the work, then it's essentially got no memory
> available. I would add significantly more swap space as well (e.g.
> add swap files to the root filesystem - you can do this while repair
> is running, too). If there's sufficient swap space, then repair
> should use it fairly efficiently - it doesn't tend to thrash swap
> because most of it's memory usage is for information that is only
> accessed once per phase or is parked until it is needed in a later
> phase so it doesn't need to be read from disk again...
> 
Good to know. However, the system was never low on swap. It has 40GB
swap available and never used more than 10GB during the repair (with 8GB
RAM). On the second run, with 16GB RAM, the xfs_repair never used any
swap at all.

On 28.10.2015 01:17, Dave Chinner wrote:
> 
> Defaults, but it's really only a guideline for cache sizing. If
> repair needs more memory to store metadata it is validating (like
> the directory structure) then it will consume as much as it needs.
> 
Will keep that in mind.

Thanks again for your help.

with kind regards,
Michael

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs



[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux