| To: | linux-xfs@xxxxxxxxxxx |
|---|---|
| Subject: | Re: XFS allows expansions, but no contraction? |
| From: | Scott McDermott <mcdermot@xxxxxxxxxxx> |
| Date: | Sat, 28 Sep 2002 22:53:18 -0400 |
| In-reply-to: | <20020928031622.A19263@wotan.suse.de>; from ak@suse.de on Sat, Sep 28, 2002 at 03:16:22AM +0200 |
| Mail-followup-to: | linux-xfs@xxxxxxxxxxx |
| References: | <3D936DFA.5060900@emergence.com> <1033072376.17558.3.camel@stout.americas.sgi.com> <1033072540.5423.17.camel@jen.americas.sgi.com> <20020928022610.A9796@wotan.suse.de> <20020927204316.F8288@questra.com> <20020928031622.A19263@wotan.suse.de> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.2.5.1i |
Andi Kleen on Sat 28/09 03:16 +0200: > > yeah right, you have XFS for /home/ and you want to tell your > > hundreds of LAN clients to remount? That is totally impractical. > > /home by definition never shrinks ... what definition? what if admin has /export/something and /export/home on different filesystems (same disk), /export/something starts nearing capacity, and he has plenty of room in /export/home to give to it? > Also would you prefer to have no shrinking to shrinking with changed > inode numbers ? I suppose a feature with a limitation is better than no feature. I think XFS is pretty heavily used for things like /export and such a feature wouldn't be very useful with changing inode numbers, but you're right that it would still be useful for some applications. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Suse 8.1 and XFS 1.1, Andi Kleen |
|---|---|
| Next by Date: | Re: slow performance with 2.4.19 and debian (SOLUTION FOUND), Corey G. |
| Previous by Thread: | Re: XFS allows expansions, but no contraction?, Andi Kleen |
| Next by Thread: | Re: XFS allows expansions, but no contraction?, Dean Roehrich |
| Indexes: | [Date] [Thread] [Top] [All Lists] |