| To: | Linux XFS <linux-xfs@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: stable xfs |
| From: | pg_xfs@xxxxxxxxxxxxxxxxxx (Peter Grandi) |
| Date: | Sat, 22 Jul 2006 19:09:40 +0100 |
| In-reply-to: | <1153413481.2768.65.camel@localhost.localdomain> |
| References: | <1153150223.4532.24.camel@localhost.localdomain> <17595.47312.720883.451573@base.ty.sabi.co.UK> <1153262166.2669.267.camel@localhost.localdomain> <17597.27469.834961.186850@base.ty.sabi.co.UK> <1153272044.2669.282.camel@localhost.localdomain> <17598.2129.999932.67127@base.ty.sabi.co.UK> <1153314670.2691.14.camel@localhost.localdomain> <20060720061527.GB18135@tuatara.stupidest.org> <1153404502.2768.50.camel@localhost.localdomain> <20060720161707.GB26748@tuatara.stupidest.org> <1153413481.2768.65.camel@localhost.localdomain> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
>>> On Thu, 20 Jul 2006 12:38:01 -0400, Ming Zhang >>> <mingz@xxxxxxxxxxx> said: [ ... ] >>> we mainly handle large media files like 20-50GB. so file >>> number is not too much. but file size is large. >> xfs_repair usually deals with that fairly well in reality >> (much better than lots of small files anyhow) > sounds cool. yes, large # of small files are always painful. It is not just number of inodes, it is also number of extents. That is total number of metadata items. [ ... ] |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: stable xfs, Peter Grandi |
|---|---|
| Next by Date: | Re: Userspace cp and ls utility, Eric Sandeen |
| Previous by Thread: | Re: stable xfs, Ming Zhang |
| Next by Thread: | Re: stable xfs, Peter Grandi |
| Indexes: | [Date] [Thread] [Top] [All Lists] |