Re: [OpenAFS] Removing a backup volume
Hi, On Fri, Jul 20, 2007 at 06:17:43PM +0200, [EMAIL PROTECTED] wrote: > Hi, > > On Fri, 20 Jul 2007, Frank Burkhardt wrote: > > >Hi, > > > >I did some benchmarks to find out, which filesystem is best: > > > >http://fbo.no-ip.org/cgi-bin/twiki/view/Instantafs/WhichFs > > thanks for sharing this. Are you reading linux-ide-arrays? There was a thread > this week > where someone pointed out that it's important to set the sunit and swidth > parameters > according to your RAID setup when creating XFS filesystems. Was your > filesystem tuned this > way? Hi, thank you for pointing me in that direction. But ... I tried using sunit/swidth and did the whole benchmark again - there was no difference regarding performance :-( . Regards, Frank ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Removing a backup volume
Hi, On Tue, Jul 24, 2007 at 02:06:45PM -0400, Dan Pritts wrote: > On Fri, Jul 20, 2007 at 05:19:37PM +0200, Frank Burkhardt wrote: > > http://fbo.no-ip.org/cgi-bin/twiki/view/Instantafs/WhichFs > > Your document says: > > > Keep in mind that ext3 sometimes thinks , it's necessary to fsck > > (e.g. after 1 year or 26x mounting). > > This is tunable with tune2fs and I think it's settable when you create > the filesystem. Correct. I didn't express this very well. What I meant is, that there seems to be some reason for a regular fsck on ext3. But as Tom Payerle pointed out: it seems to be feature which has a default that might not match my needs 100% but that's still usefull. I initially misinterpreted that feature as an indication that ext3 is "so much broken" that it needs regular checking. Regards, Frank ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Removing a backup volume
On Fri, Jul 20, 2007 at 05:19:37PM +0200, Frank Burkhardt wrote: > http://fbo.no-ip.org/cgi-bin/twiki/view/Instantafs/WhichFs Your document says: > Keep in mind that ext3 sometimes thinks , it's necessary to fsck > (e.g. after 1 year or 26x mounting). This is tunable with tune2fs and I think it's settable when you create the filesystem. danno -- Dan Pritts, System Administrator Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224 Internet2 Workshops: More fun than summer school http://www.internet2.edu/workshops ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Removing a backup volume
On Jul 20, 2007, at 2:18 PM, Michael C Garrison wrote: On Fri, 20 Jul 2007, Frank Burkhardt wrote: Sorry. It's 1.4.4 - I just updated the page. Cool. I imagine your XFS performance would improve greatly with the no fsync patch that's been discussed on here. And a few comments on reiser. If you ever need to do a fsck on it (which we have in our IMAP environment) the time it takes is really-really-really long for large partitions (7+ days). We've since moved away from reiser due to stability issues and back to ext3. I tested fsck time, too. Have a look at the table - it was ~4,5x faster than ext3. Yeah, but I'd suggest you test reiserfsck with the --rebuild-tree option and see how long it takes then. We ran into corruption that would require rebuilding the B-trees and this is what takes a very long time. Correct. When the chart says 'fsck', it's not doing an apples and apples comparison. Your manager might not be happy when that 177 second fsck becomes 600,000 seconds. There have been a number of fruitless discussions of how well a truly damaged Reiser fs can actually be recovered on various other mailing list. I have no idea which party to the discussion is correct, but until there is better data I don't see enough win in Reiser to be worth the small-but-undetermined possibility of a long outage. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Removing a backup volume
On Fri, 20 Jul 2007, Frank Burkhardt wrote: Sorry. It's 1.4.4 - I just updated the page. Cool. I imagine your XFS performance would improve greatly with the no fsync patch that's been discussed on here. And a few comments on reiser. If you ever need to do a fsck on it (which we have in our IMAP environment) the time it takes is really-really-really long for large partitions (7+ days). We've since moved away from reiser due to stability issues and back to ext3. I tested fsck time, too. Have a look at the table - it was ~4,5x faster than ext3. Yeah, but I'd suggest you test reiserfsck with the --rebuild-tree option and see how long it takes then. We ran into corruption that would require rebuilding the B-trees and this is what takes a very long time. -- Mike Garrison ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Removing a backup volume
Hi, On Fri, 20 Jul 2007, Frank Burkhardt wrote: Hi, I did some benchmarks to find out, which filesystem is best: http://fbo.no-ip.org/cgi-bin/twiki/view/Instantafs/WhichFs thanks for sharing this. Are you reading linux-ide-arrays? There was a thread this week where someone pointed out that it's important to set the sunit and swidth parameters according to your RAID setup when creating XFS filesystems. Was your filesystem tuned this way? Now my boss want's me to use ext3, I would prefer reiser3 - difficult decision :-) . Unless your hardware never fails, or reiserfsck has become much, much better than the last time I (would have) needed it, your boss is right ;-) Regards, Stephan Regards, Frank ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info -- Stephan Wiesand DESY - DV - Platanenallee 6 15738 Zeuthen, Germany ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Removing a backup volume
On Fri, 20 Jul 2007, Frank Burkhardt wrote: Hi, I did some benchmarks to find out, which filesystem is best: http://fbo.no-ip.org/cgi-bin/twiki/view/Instantafs/WhichFs Now my boss want's me to use ext3, I would prefer reiser3 - difficult decision :-) . What version of OpenAFS did you test with? And a few comments on reiser. If you ever need to do a fsck on it (which we have in our IMAP environment) the time it takes is really-really-really long for large partitions (7+ days). We've since moved away from reiser due to stability issues and back to ext3. -- Mike Garrison ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Removing a backup volume
Thanks for this, Frank. Kim Kimball Frank Burkhardt wrote: Hi, I did some benchmarks to find out, which filesystem is best: http://fbo.no-ip.org/cgi-bin/twiki/view/Instantafs/WhichFs Now my boss want's me to use ext3, I would prefer reiser3 - difficult decision :-) . Regards, Frank ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Removing a backup volume
Hi, I did some benchmarks to find out, which filesystem is best: http://fbo.no-ip.org/cgi-bin/twiki/view/Instantafs/WhichFs Now my boss want's me to use ext3, I would prefer reiser3 - difficult decision :-) . Regards, Frank ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Removing a backup volume
Hi, On Mon, Jun 25, 2007 at 04:46:29PM -0400, Steven Jenkins wrote: > On 6/25/07, Derrick Brashear <[EMAIL PROTECTED]> wrote: > > > > > > > >On 6/25/07, Steven Jenkins <[EMAIL PROTECTED]> wrote:... > > > > > >The root problem here is the underlying filesystem presumably offers poor > >performance for deleting files, and the way to fix it is to use a filesystem > >that doesn't. Deleting a volume is really deleting a tree of files and > >directories, and it won't run any faster for OpenAFS than it does for > >anything else. I'm just trying a different filesystem on one of my servers (Reiserfs). Maybe XFS is a poor choice for AFS. > Frank, let me ask some additional questions: > > * What OS are you on? (including distribution, release, etc) > * What is the underlying filesystem? what features do you have enabled? ( Filesystem is XFS (no options used for mkfs.xfs). OS information can be found in my first mail (digest: OS=Debian Etch 4.0, Kernel=2.6.21.0 (vanilla;self-compiled), Openafs=1.4.4). > With that information, we might be able to help explain things more clearly > and completely. Thank you, Frank ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Removing a backup volume
On 6/25/07, Derrick Brashear <[EMAIL PROTECTED]> wrote: On 6/25/07, Steven Jenkins <[EMAIL PROTECTED]> wrote:... The root problem here is the underlying filesystem presumably offers poor performance for deleting files, and the way to fix it is to use a filesystem that doesn't. Deleting a volume is really deleting a tree of files and directories, and it won't run any faster for OpenAFS than it does for anything else. Frank, let me ask some additional questions: * What OS are you on? (including distribution, release, etc) * What is the underlying filesystem? what features do you have enabled? ( e.g., the output of dumpe2fs -h or equivalent on your system) With that information, we might be able to help explain things more clearly and completely. Thanks, Steven
Re: [OpenAFS] Removing a backup volume
On 6/25/07, Steven Jenkins <[EMAIL PROTECTED]> wrote: On 6/18/07, Frank Burkhardt <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm currently removing a backup clone which belongs to a volume > containing ~ > 55 GB in ~ 102000 files. 'vos status' shows a "DeleteVolume" transaction > which is running since 63 min now. > > Is it supposed to take that long? I've seen this on all of our file > servers > - especially when performing clone operations (e.g. vos backup, vos > release). However: cpus are ~99.5% idle (cpu load is always ~1.0 ). The > fileserver removes the clone exclusively - noone else accesses content > from > the volume's volumegroup and it's the only volume on the server. > > Is there a way to speed things up? > My understanding (as this problem was described to me last week) is that this is 'normal' and 'expected'. It's certainly not optimal. There are no simple suggestions I know of that will speed up these operations; however, there have been some discussions around how to speed this up. The root problem here is the underlying filesystem presumably offers poor performance for deleting files, and the way to fix it is to use a filesystem that doesn't. Deleting a volume is really deleting a tree of files and directories, and it won't run any faster for OpenAFS than it does for anything else. What's the problem, exactly? Impatience or is there an actual operational issue? Derrick
Re: [OpenAFS] Removing a backup volume
On 6/18/07, Frank Burkhardt <[EMAIL PROTECTED]> wrote: Hi, I'm currently removing a backup clone which belongs to a volume containing ~ 55 GB in ~ 102000 files. 'vos status' shows a "DeleteVolume" transaction which is running since 63 min now. Is it supposed to take that long? I've seen this on all of our file servers - especially when performing clone operations (e.g. vos backup, vos release). However: cpus are ~99.5% idle (cpu load is always ~1.0 ). The fileserver removes the clone exclusively - noone else accesses content from the volume's volumegroup and it's the only volume on the server. Is there a way to speed things up? My understanding (as this problem was described to me last week) is that this is 'normal' and 'expected'. It's certainly not optimal. There are no simple suggestions I know of that will speed up these operations; however, there have been some discussions around how to speed this up. I may be wrong, however. Steven
