Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*XFS\s+shrink\s+functionality\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*XFS\s+shrink\s+functionality\s*$/: 32 ]

Total 32 documents matching your query.

1. XFS shrink functionality (score: 1): Author: Ruben Porras <nahoo82@xxxxxxxxx>; Date: Fri, 01 Jun 2007 18:39:34 +0200; I'm investigating the possibility to write myself the necessary code to shrink an xfs filesystem (I'd be able to dedicate a day/week). Trying to know if something is already done I came across the m; /archives/xfs/2007-06/msg00000.html (9,599 bytes)
2. Re: XFS shrink functionality (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Mon, 4 Jun 2007 10:16:32 +1000; Oh, thanks for pointing those out - they're before my time ;) Any work for this would need to be done against current mainline of the xfs-dev tree. Yes, that patch is out of date, and it also did thi; /archives/xfs/2007-06/msg00023.html (13,088 bytes)
3. Re: XFS shrink functionality (score: 1): Author: Iustin Pop <iusty@xxxxxxxxx>; Date: Mon, 4 Jun 2007 10:41:54 +0200; Disclaimer: all the below is based on my weak understanding of the code, I don't claim I'm right below. Well, I did what I could based on my own understanding of the code. Sorry if it's ugly :) My id; /archives/xfs/2007-06/msg00044.html (15,340 bytes)
4. Re: XFS shrink functionality (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Mon, 4 Jun 2007 19:21:15 +1000; Yes, that is one way of looking at it.... Copying is not good enough - attributes must remain unchanged. The only thing we can't preserve is the inode number.... Not quite that simple, unfortunately.; /archives/xfs/2007-06/msg00045.html (18,080 bytes)
5. Re: XFS shrink functionality (score: 1): Author: Iustin Pop <iusty@xxxxxxxxx>; Date: Tue, 5 Jun 2007 10:00:12 +0200; A question: do you think that the cost of having this in the code (especially the last part, check that flag in every allocation function) is acceptable? I mean, let's say one would write the patch t; /archives/xfs/2007-06/msg00074.html (13,031 bytes)
6. Re: XFS shrink functionality (score: 1): Author: Nathan Scott <nscott@xxxxxxxxxx>; Date: Wed, 06 Jun 2007 11:50:10 +1000; Theres no doubt that its useful, its probably the most frequently requested feature for XFS from the community. I'd imagine its acceptance will depend on code quality, testing, etc, etc. IIRC, most p; /archives/xfs/2007-06/msg00086.html (10,256 bytes)
7. Re: XFS shrink functionality (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Thu, 7 Jun 2007 18:18:30 +1000; Lots of ppl ask for shrink capability on XFS, so if it's implemented and reviewed and passes QA tests, then I see no reason why it wouldn't be accepted... Look at it this way - if we get to the point; /archives/xfs/2007-06/msg00102.html (13,632 bytes)
8. Re: XFS shrink functionality (score: 1): Author: Ruben Porras <nahoo82@xxxxxxxxx>; Date: Fri, 08 Jun 2007 10:23:53 +0200; Am Montag, den 04.06.2007, 10:41 +0200 schrieb Iustin Pop: there is now a document explaining the XFS on disk format [0] and some presentations for training courses, I think none of this were availab; /archives/xfs/2007-06/msg00128.html (11,673 bytes)
9. Re: XFS shrink functionality (score: 1): Author: Iustin Pop <iusty@xxxxxxxxx>; Date: Fri, 8 Jun 2007 12:15:32 +0200; Yes, just yesterday I found the document and it helps. Not after that in the cronological sense, but in the importance part. Yes, it was a bad choice of words. I took a look at both items since this; /archives/xfs/2007-06/msg00132.html (12,869 bytes)
10. Re: XFS shrink functionality (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Sat, 9 Jun 2007 00:44:55 +1000; There's thousands of lines of code documenting that format as well ;) I think walking the filesystem can be avoided effectively by introducing an reverse map that points to the owner of the block. (i; /archives/xfs/2007-06/msg00134.html (10,830 bytes)
11. Re: XFS shrink functionality (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Sat, 9 Jun 2007 01:12:23 +1000; one new transaction type: XFS_TRANS_AGF_FLAGS and and extension to xfs_alloc_log_agf(). Is about all that is needed there. See the patch here: http://oss.sgi.com/archives/xfs/2007-04/msg00103.html Fo; /archives/xfs/2007-06/msg00135.html (14,124 bytes)
12. Re: XFS shrink functionality (score: 1): Author: Iustin Pop <iusty@xxxxxxxxx>; Date: Fri, 8 Jun 2007 18:03:18 +0200; Ah, I see now. I was wondering how one can enable the new bits (CVS xfs_db shows the btreeblks but 'version' cmd doesn't allow to change them), it seems that manual xfs_db work + xfs_repair allows th; /archives/xfs/2007-06/msg00139.html (14,211 bytes)
13. Re: XFS shrink functionality (score: 1): Author: Ruben Porras <nahoo82@xxxxxxxxx>; Date: Fri, 08 Jun 2007 21:47:38 +0200; Am Samstag, den 09.06.2007, 01:12 +1000 schrieb David Chinner: Thank you, these last mail explains the pieces I should do pretty well :) Cheers; /archives/xfs/2007-06/msg00142.html (10,525 bytes)
14. Re: XFS shrink functionality (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Sat, 9 Jun 2007 12:15:35 +1000; The xfs_db work needs to be wrapped up in xfs_admin. That's relatively simple to do, but the repair stage is needed to count the btree blocks and update the counter in eah AGF. That could probably al; /archives/xfs/2007-06/msg00143.html (14,349 bytes)
15. Re: XFS shrink functionality (score: 1): Author: Ruben Porras <nahoo82@xxxxxxxxx>; Date: Thu, 14 Jun 2007 10:35:27 +0200; done still to do. Will come after the ioctls. almost done. How I'm should I obtain a pointer to an xfs_agf_t from inside the ioctls? I guess that the first step is to get a *bp with xfs_getsb and th; /archives/xfs/2007-06/msg00210.html (12,825 bytes)
16. Re: XFS shrink functionality (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Thu, 14 Jun 2007 19:14:26 +1000; FWIW, I've had second thoughts on this ioctl interface. It's horribly specific, considering all we are doing are setting or clearing a flag in an AG. Perhaps a better interface is: XFS_IOC_GET_AGF_FL; /archives/xfs/2007-06/msg00212.html (20,758 bytes)
17. XFS shrink functionality (score: 1): Author: Ruben Porras <nahoo82@xxxxxxxxx>; Date: Fri, 01 Jun 2007 18:39:34 +0200; I'm investigating the possibility to write myself the necessary code to shrink an xfs filesystem (I'd be able to dedicate a day/week). Trying to know if something is already done I came across the m; /archives/xfs/2007-06/msg00493.html (9,599 bytes)
18. Re: XFS shrink functionality (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Mon, 4 Jun 2007 10:16:32 +1000; Oh, thanks for pointing those out - they're before my time ;) Any work for this would need to be done against current mainline of the xfs-dev tree. Yes, that patch is out of date, and it also did thi; /archives/xfs/2007-06/msg00516.html (13,088 bytes)
19. Re: XFS shrink functionality (score: 1): Author: Iustin Pop <iusty@xxxxxxxxx>; Date: Mon, 4 Jun 2007 10:41:54 +0200; Disclaimer: all the below is based on my weak understanding of the code, I don't claim I'm right below. Well, I did what I could based on my own understanding of the code. Sorry if it's ugly :) My id; /archives/xfs/2007-06/msg00537.html (15,340 bytes)
20. Re: XFS shrink functionality (score: 1): Author: David Chinner <dgc@xxxxxxx>; Date: Mon, 4 Jun 2007 19:21:15 +1000; Yes, that is one way of looking at it.... Copying is not good enough - attributes must remain unchanged. The only thing we can't preserve is the inode number.... Not quite that simple, unfortunately.; /archives/xfs/2007-06/msg00538.html (18,080 bytes)

Current List: 1 - 20
Page: [1] [2]