Re: gmirror on existing filesystem (was Fresh install on gmirror'ed disks?)
On Thu, Apr 06, 2006 at 09:33:31AM -0400, Mike Jakubik wrote: +> Pawel Jakub Dawidek wrote: +> >One can still see how many sectors exactly has the partition he is going +> >to create file system on and add additional newfs(8) flag +> >'-s '. +> > +> +> "gmirror utility uses on-disk metadata (stored in the provider's last sector) to store all needed information." +> +> Would creating a freebsd partition thats slightly smaller than the disk resolve the issue (when mirroring the entire disk)? or does it still use the last sector of the +> label? I'm not sure what one means by "provider" in this case. "provider" in this case is what you use to create mirror on. If you do it by: # gmirror label foo ad0 ad2 Then disks ad0 and ad2 are providers where gmirror puts metadata in their last sector. In most cases, you create slices and then partitions. If you configure a mirror on partitions, eg. # gmirror label foo ad0s1a ad2s1a then you need to create file system one sector smaller with newfs(8) when you do it on adXs1a. When you configure a mirror on slices, eg. # gmirror label foo ad0s1 ad2s1 then your last partition created on adXs1 must end up before the slice end (its offset+size should be one sector smaller than the size of the slice). When you configure a mirror on disks, eg. # gmirror label foo ad0 ad2 then your last slice created on adXs1 have to end up before the disk end (just like in the previous case). In most cases, last slice ends before the disk end, leaving plenty of space at the end, so you should be safe here. In other cases the whole space is allocated (not sure if really used). In any case, system may complain if information about the original provider size is stored somewhere, ie. partitions were created on one sector bigger slice than gmirror provider, so 'c' partition will be one sector too large. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp9qa9rGnv2S.pgp Description: PGP signature
Re: gmirror on existing filesystem (was Fresh install on gmirror'ed disks?)
Pawel Jakub Dawidek wrote: On Tue, Apr 04, 2006 at 05:51:26PM -0400, Mike Jakubik wrote: +> >>>Can someone with knowledge of the UFS internals please confirm one way +> >>>or the other if this is dangerous or not? +> >>> +> >> +> >>I'm curious to know this as well, as i have some systems using gmirror, that were setup in this fashion. Could someone knowledgeable on the matter shed some light? +> > +> > +> >I've gmirrored existing disks/slices before, and it's worked fine. I'm not 100% certain about all cases, but it's possible that the filesystem could be right up against +> >the last block of the partition, and it could get stomped on I suppose. +> > +> >I'm not sure what this command tells you for sure, but it dumps the last block of a slice, or disk, or whatever: +> > +> > +> >dd if=/dev/ad0s3a iseek=`diskinfo ad0s3a | perl -ne '@d = split; print ($d[2]/$d[1] - 1)'` count=512 | hexdump +> +> Could someone provide an authoritative answer to this please? Pawel, it would be nice to see some support for your own code from you. This is a very easy method to create a +> mirror on an existing system, but if its going to cause problems then its useless (All the more reason for geom enabled installer). I can't give you an authoritative answer, because I don't know UFS internals so well. All I know is that it (UFS) thinks the last sector is available and may want to use it at some point getting EIO then. I'm not using this method, but I've heard of many people using it without problems. Speaking about installer. I don't think I'll be able to add configuration of my GEOM classes to the sysinstall in the near future (and I hope never - I'd prefer to wait for a new installer). One can still see how many sectors exactly has the partition he is going to create file system on and add additional newfs(8) flag '-s '. I suppose one could look at the output of diskinfo, and compare against the output of df, and see if there is a spare 512+ bytes at the end of the partition. I think there's a possibility that newfs won't use the last chunk if it's less than BLOCKSIZE bytes.. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror on existing filesystem (was Fresh install on gmirror'ed disks?)
On Apr 6, 2006, at 4:12 AM, Pawel Jakub Dawidek wrote: I can't give you an authoritative answer, because I don't know UFS internals so well. All I know is that it (UFS) thinks the last sector is available and may want to use it at some point getting EIO then. Well, my ovservation from using "diskinfo -t -v" on my /dev/ad4 device and then on the /dev/mirror/gm0 device after the mirror create shows a slightly smaller mediasize. Now, whether the UFS knows it is smaller or not, I can't say, but the lower level of the OS is reporting a smaller media size. In any case, every time I partition a disk, fdisk always leaves a bunch of sectors hanging off the end. I presume that's where gmirror stores its data for whole-disk mirror... at least I'd hope! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror on existing filesystem (was Fresh install on gmirror'ed disks?)
Pawel Jakub Dawidek wrote: I can't give you an authoritative answer, because I don't know UFS internals so well. All I know is that it (UFS) thinks the last sector is available and may want to use it at some point getting EIO then. I'm not using this method, but I've heard of many people using it without problems. Thanks, I guess better safe than sorry then. Speaking about installer. I don't think I'll be able to add configuration of my GEOM classes to the sysinstall in the near future (and I hope never - I'd prefer to wait for a new installer). I wasn't suggesting you do it, i know there are people working on a new installer, and this has been mentioned already. It's on their "to do" list, but who knows when we will see it. One can still see how many sectors exactly has the partition he is going to create file system on and add additional newfs(8) flag '-s '. "gmirror utility uses on-disk metadata (stored in the provider's last sector) to store all needed information." Would creating a freebsd partition thats slightly smaller than the disk resolve the issue (when mirroring the entire disk)? or does it still use the last sector of the label? I'm not sure what one means by "provider" in this case. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror on existing filesystem (was Fresh install on gmirror'ed disks?)
On Tue, Apr 04, 2006 at 05:51:26PM -0400, Mike Jakubik wrote: +> >>>Can someone with knowledge of the UFS internals please confirm one way +> >>>or the other if this is dangerous or not? +> >>> +> >> +> >>I'm curious to know this as well, as i have some systems using gmirror, that were setup in this fashion. Could someone knowledgeable on the matter shed some light? +> > +> > +> >I've gmirrored existing disks/slices before, and it's worked fine. I'm not 100% certain about all cases, but it's possible that the filesystem could be right up against +> >the last block of the partition, and it could get stomped on I suppose. +> > +> >I'm not sure what this command tells you for sure, but it dumps the last block of a slice, or disk, or whatever: +> > +> > +> >dd if=/dev/ad0s3a iseek=`diskinfo ad0s3a | perl -ne '@d = split; print ($d[2]/$d[1] - 1)'` count=512 | hexdump +> +> Could someone provide an authoritative answer to this please? Pawel, it would be nice to see some support for your own code from you. This is a very easy method to create a +> mirror on an existing system, but if its going to cause problems then its useless (All the more reason for geom enabled installer). I can't give you an authoritative answer, because I don't know UFS internals so well. All I know is that it (UFS) thinks the last sector is available and may want to use it at some point getting EIO then. I'm not using this method, but I've heard of many people using it without problems. Speaking about installer. I don't think I'll be able to add configuration of my GEOM classes to the sysinstall in the near future (and I hope never - I'd prefer to wait for a new installer). One can still see how many sectors exactly has the partition he is going to create file system on and add additional newfs(8) flag '-s '. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpEmArL2ynOc.pgp Description: PGP signature
Re: gmirror on existing filesystem (was Fresh install on gmirror'ed disks?)
Eric Anderson wrote: Mike Jakubik wrote: Craig Boston wrote: On Tue, Mar 07, 2006 at 09:04:02AM -0800, Freddie Cash wrote: There's no need to copy files around. gmirror handles it all for you behind the scenes. Just create the gmirror labels using the existing disks/slices/partitions, then insert the second set of disks/slices/parittions. gmirror will handle synchonising the data across the mirror. AFAIK, gmirror causes whatever provider it's mirroring to "lose" the last block to metadata. I've always avoided mirroring an existing filesystem for fear that shrinking a UFS filesystem's underlying device might cause problems down the road. Can someone with knowledge of the UFS internals please confirm one way or the other if this is dangerous or not? I'm curious to know this as well, as i have some systems using gmirror, that were setup in this fashion. Could someone knowledgeable on the matter shed some light? I've gmirrored existing disks/slices before, and it's worked fine. I'm not 100% certain about all cases, but it's possible that the filesystem could be right up against the last block of the partition, and it could get stomped on I suppose. I'm not sure what this command tells you for sure, but it dumps the last block of a slice, or disk, or whatever: dd if=/dev/ad0s3a iseek=`diskinfo ad0s3a | perl -ne '@d = split; print ($d[2]/$d[1] - 1)'` count=512 | hexdump Could someone provide an authoritative answer to this please? Pawel, it would be nice to see some support for your own code from you. This is a very easy method to create a mirror on an existing system, but if its going to cause problems then its useless (All the more reason for geom enabled installer). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror on existing filesystem (was Fresh install on gmirror'ed disks?)
Mike Jakubik wrote: Craig Boston wrote: On Tue, Mar 07, 2006 at 09:04:02AM -0800, Freddie Cash wrote: There's no need to copy files around. gmirror handles it all for you behind the scenes. Just create the gmirror labels using the existing disks/slices/partitions, then insert the second set of disks/slices/parittions. gmirror will handle synchonising the data across the mirror. AFAIK, gmirror causes whatever provider it's mirroring to "lose" the last block to metadata. I've always avoided mirroring an existing filesystem for fear that shrinking a UFS filesystem's underlying device might cause problems down the road. Can someone with knowledge of the UFS internals please confirm one way or the other if this is dangerous or not? I'm curious to know this as well, as i have some systems using gmirror, that were setup in this fashion. Could someone knowledgeable on the matter shed some light? I've gmirrored existing disks/slices before, and it's worked fine. I'm not 100% certain about all cases, but it's possible that the filesystem could be right up against the last block of the partition, and it could get stomped on I suppose. I'm not sure what this command tells you for sure, but it dumps the last block of a slice, or disk, or whatever: dd if=/dev/ad0s3a iseek=`diskinfo ad0s3a | perl -ne '@d = split; print ($d[2]/$d[1] - 1)'` count=512 | hexdump Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror on existing filesystem (was Fresh install on gmirror'ed disks?)
Craig Boston wrote: On Tue, Mar 07, 2006 at 09:04:02AM -0800, Freddie Cash wrote: There's no need to copy files around. gmirror handles it all for you behind the scenes. Just create the gmirror labels using the existing disks/slices/partitions, then insert the second set of disks/slices/parittions. gmirror will handle synchonising the data across the mirror. AFAIK, gmirror causes whatever provider it's mirroring to "lose" the last block to metadata. I've always avoided mirroring an existing filesystem for fear that shrinking a UFS filesystem's underlying device might cause problems down the road. Can someone with knowledge of the UFS internals please confirm one way or the other if this is dangerous or not? I'm curious to know this as well, as i have some systems using gmirror, that were setup in this fashion. Could someone knowledgeable on the matter shed some light? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
