| To: | Steve Lord <lord@xxxxxxx> |
|---|---|
| Subject: | Re: XFS allows expansions, but no contraction? |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Sat, 28 Sep 2002 02:26:10 +0200 |
| Cc: | Eric Sandeen <sandeen@xxxxxxx>, Michael Best <mbest@xxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <1033072540.5423.17.camel@jen.americas.sgi.com> |
| References: | <3D936DFA.5060900@emergence.com> <1033072376.17558.3.camel@stout.americas.sgi.com> <1033072540.5423.17.camel@jen.americas.sgi.com> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.3.22.1i |
> Probably an extension of the xfs_fsr approach would be the way to > go. One major issue is it is impossible to do this without changing > inode numbers. Some applications rely on inode numbers remaining a > constant. But none I know do this over umount/remount (ok except for NFS stateless filehandles, but that can be cured by remounting on the client too) So when you limit yourself to doing the shrinking offline (which I think would be ok for most users) then this would be no problem. I guess adding hot-shrinking would be a locking nightmare anyways, because one would need to add checks everywhere in the fs that the blocks it just allocated didn't go away ... -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: patch to give kmalloc a chance (RFC), Andrew Morton |
|---|---|
| Next by Date: | Re: XFS allows expansions, but no contraction?, Scott McDermott |
| Previous by Thread: | Re: XFS allows expansions, but no contraction?, Steve Lord |
| Next by Thread: | Re: XFS allows expansions, but no contraction?, Scott McDermott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |