| To: | Steve Lord <lord@xxxxxxx> |
|---|---|
| Subject: | Re: XFS holding onto disk memory |
| From: | Chris Wedgwood <cw@xxxxxxxx> |
| Date: | Wed, 26 Mar 2003 21:20:44 -0800 |
| Cc: | Walt H <waltabbyh@xxxxxxxxxxx>, Mark Grimes <MGrimes@xxxxxxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxx>, "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx> |
| In-reply-to: | <1048731703.1119.15.camel@xxxxxxxxxxxxxxxxxxxxxxx> |
| References: | <057889C7F1E5D61193620002A537E8690AD0AA@NCBDC> <1048706978.23087.83.camel@xxxxxxxxxxxxxxxxxxxx> <3E825CA5.6010007@xxxxxxxxxxx> <1048731703.1119.15.camel@xxxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.3.28i |
On Wed, Mar 26, 2003 at 08:21:43PM -0600, Steve Lord wrote:
> It would yes, but we are not currently planning on offering
> facilities to clean up existing filesystems. Over time inode
> clusters would be freed, but only as inodes were allocated in them
> and freed again.
Surely getting the fs to clean up after itself wouldn't be to hard?
Something like:
foreach ag ;
create dir<ag_num>
do 100k times
create file dir<agnum>/foo<file_num>
<pause, print pretty message or whatever>
foreach ag ;
do 100k times
remove file dir<ag_num>/foo<file_num>
rmdir dir<ag_num>
would suffice?
--cw
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | 2.4.20 CVS, Joshua Schmidlkofer |
|---|---|
| Next by Date: | Re: kernel patch fail with LVM, Nathan Scott |
| Previous by Thread: | Re: XFS holding onto disk memory, Steve Lord |
| Next by Thread: | Updated kernels with ptrace bugfix?, Kai Leibrandt |
| Indexes: | [Date] [Thread] [Top] [All Lists] |