* Re: xfsdump INTERRUPT issue [not found] <CCE505AA.B05B7%jellis@dhnet.us> @ 2012-12-06 1:38 ` Stan Hoeppner 2012-12-06 2:08 ` Jeffrey Ellis 0 siblings, 1 reply; 28+ messages in thread From: Stan Hoeppner @ 2012-12-06 1:38 UTC (permalink / raw) To: J. Ellis, xfs@oss.sgi.com On 12/5/2012 1:07 PM, J. Ellis wrote: This should never have gone off list so I'm copying back. If you'd have kept this on list you'd have likely already had an answer to this. Going off list for fear of looking ignorant is not a valid reason to do so. In fact there are very few reasons to ever go off list. All it does is take people out of the loop who are watching the thread and may be willing to jump in at some point to help. You've short circuited that by going off list. > I just read the man page again. There doesn't seem to be any examples I can > find to write the dump to a file. I couldn't find a -t option in the man at > all, so maybe the ones I'm finding aren't up to date. Here's the only > example I can find, and I don't know if this would actually work: > > xfsdump -f /usr/tmp/monday_backup -v silent -J -s \ people/fred/Makefile -s > people/fred/Source /usr This is really simple. Using my previous example, we want to dump to a test file and not update the inventory. So we have something like: ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6 This dumps the XFS filesystem on /dev/sda6 to a file. Don't write the dump file to the filesystem you're dumping. Preferably the XFS you're dumping is on one disk or array and the target file will be written to a different disk or array. Dumps are IO intensive. I clearly stated the "-t" option in the context of xfsrestore: -t Displays the contents of the dump, but does not create or modify any files or directories. It may be desirable to set the verbosity level to silent when using this option. This allows you to do a test run without actually writing any files during the restore. The goal here is to test xfsdump and xfsrestore on your system to see where errors are cropping up. You don't actually want to restore the dumped filesystem at this point. The "-v" option simply keeps the "-t" from spamming a million file names to your console during the restore operation. -- Stan > on 12/4/12 10:32 PM, Stan Hoeppner at stan@hardwarefreak.com wrote: > >> On 12/4/2012 7:18 PM, J. Ellis wrote: >>> Hi, Stan-- >>> >>> Ok, I truly apologize for my ignorance, but I don't know how to dump the >>> contents to a file. Is it something like: >>> >>> xfsdump -J - somefile_xfsdump.txt >> >> ~$ man xfsdump >> >> Look at option "-f". >> >>> xfsrestore -J - somefile_xfsrestore.txt >> >> ~$ man xfsrestore >> >> See options "-f" "-t" and "-v". >> >> The point of this exercise I believe is to see what errors are thrown by >> xfsdump or xfsrestore when they are executed independently, vs through a >> pipe. Do note that this may not be the final step in testing before you >> have an answer. Post any errors or informational output that results >> from these commands. >> >> Note that the file written by xfsdump is going to be about the same size >> as the filesystem being dumped. I.e. if the filesystem being dumped is >> 1TB then you need 1TB of free space on the device where the target >> directory resides--you're dumping an entire XFS filesystem into a single >> file. Also, be sure to use "-t" so xfsrestore doesn't actually write >> anything. Did you read "-v"? > > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-06 1:38 ` xfsdump INTERRUPT issue Stan Hoeppner @ 2012-12-06 2:08 ` Jeffrey Ellis 2012-12-06 2:40 ` Stan Hoeppner 0 siblings, 1 reply; 28+ messages in thread From: Jeffrey Ellis @ 2012-12-06 2:08 UTC (permalink / raw) To: stan@hardwarefreak.com; +Cc: xfs@oss.sgi.com Hi, Stan-- You're right. I didn't want to look stupid. Sorry. I'll keep it all on the list from now on. Thank you for the example. I hope I have this right. So including the -t and -v would be ~$ xfsdump -J -f -t -v /xfsdump_file /dev/sda0 Repeat for each mount point, and post the result here? Thanks again. Jeffrey > ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6 Best, J. On Dec 5, 2012, at 8:38 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote: > On 12/5/2012 1:07 PM, J. Ellis wrote: > > This should never have gone off list so I'm copying back. If you'd have > kept this on list you'd have likely already had an answer to this. > Going off list for fear of looking ignorant is not a valid reason to do > so. In fact there are very few reasons to ever go off list. All it > does is take people out of the loop who are watching the thread and may > be willing to jump in at some point to help. You've short circuited > that by going off list. > >> I just read the man page again. There doesn't seem to be any examples I can >> find to write the dump to a file. I couldn't find a -t option in the man at >> all, so maybe the ones I'm finding aren't up to date. Here's the only >> example I can find, and I don't know if this would actually work: >> >> xfsdump -f /usr/tmp/monday_backup -v silent -J -s \ people/fred/Makefile -s >> people/fred/Source /usr > > This is really simple. Using my previous example, we want to dump to a > test file and not update the inventory. So we have something like: > > ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6 > > This dumps the XFS filesystem on /dev/sda6 to a file. Don't write the > dump file to the filesystem you're dumping. Preferably the XFS you're > dumping is on one disk or array and the target file will be written to a > different disk or array. Dumps are IO intensive. > > I clearly stated the "-t" option in the context of xfsrestore: > > -t Displays the contents of the dump, but does not create or > modify any files or directories. It may be desirable to > set the verbosity level to silent when using this option. > > This allows you to do a test run without actually writing any files > during the restore. The goal here is to test xfsdump and xfsrestore on > your system to see where errors are cropping up. You don't actually > want to restore the dumped filesystem at this point. > > The "-v" option simply keeps the "-t" from spamming a million file names > to your console during the restore operation. > > -- > Stan > > >> on 12/4/12 10:32 PM, Stan Hoeppner at stan@hardwarefreak.com wrote: >> >>> On 12/4/2012 7:18 PM, J. Ellis wrote: >>>> Hi, Stan-- >>>> >>>> Ok, I truly apologize for my ignorance, but I don't know how to dump the >>>> contents to a file. Is it something like: >>>> >>>> xfsdump -J - somefile_xfsdump.txt >>> >>> ~$ man xfsdump >>> >>> Look at option "-f". >>> >>>> xfsrestore -J - somefile_xfsrestore.txt >>> >>> ~$ man xfsrestore >>> >>> See options "-f" "-t" and "-v". >>> >>> The point of this exercise I believe is to see what errors are thrown by >>> xfsdump or xfsrestore when they are executed independently, vs through a >>> pipe. Do note that this may not be the final step in testing before you >>> have an answer. Post any errors or informational output that results >>> from these commands. >>> >>> Note that the file written by xfsdump is going to be about the same size >>> as the filesystem being dumped. I.e. if the filesystem being dumped is >>> 1TB then you need 1TB of free space on the device where the target >>> directory resides--you're dumping an entire XFS filesystem into a single >>> file. Also, be sure to use "-t" so xfsrestore doesn't actually write >>> anything. Did you read "-v"? > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-06 2:08 ` Jeffrey Ellis @ 2012-12-06 2:40 ` Stan Hoeppner [not found] ` <6F909666-9DFE-43F1-973D-170B892F9C5B@gmail.com> 0 siblings, 1 reply; 28+ messages in thread From: Stan Hoeppner @ 2012-12-06 2:40 UTC (permalink / raw) To: xfs On 12/5/2012 8:08 PM, Jeffrey Ellis wrote: > Hi, Stan-- > > You're right. I didn't want to look stupid. Sorry. I'll keep it all on the list from now on. > > Thank you for the example. I hope I have this right. So including the -t and -v would be > > ~$ xfsdump -J -f -t -v /xfsdump_file /dev/sda0 No. That's not right. I gave you concise separate instructions for xfsdump and for xfsrestore, and you've commingled the two. Please thoroughly and thoughtfully re-read my last email. -- Stan > Repeat for each mount point, and post the result here? > > Thanks again. > Jeffrey > >> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6 > > > > Best, > J. > > On Dec 5, 2012, at 8:38 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote: > >> On 12/5/2012 1:07 PM, J. Ellis wrote: >> >> This should never have gone off list so I'm copying back. If you'd have >> kept this on list you'd have likely already had an answer to this. >> Going off list for fear of looking ignorant is not a valid reason to do >> so. In fact there are very few reasons to ever go off list. All it >> does is take people out of the loop who are watching the thread and may >> be willing to jump in at some point to help. You've short circuited >> that by going off list. >> >>> I just read the man page again. There doesn't seem to be any examples I can >>> find to write the dump to a file. I couldn't find a -t option in the man at >>> all, so maybe the ones I'm finding aren't up to date. Here's the only >>> example I can find, and I don't know if this would actually work: >>> >>> xfsdump -f /usr/tmp/monday_backup -v silent -J -s \ people/fred/Makefile -s >>> people/fred/Source /usr >> >> This is really simple. Using my previous example, we want to dump to a >> test file and not update the inventory. So we have something like: >> >> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6 >> >> This dumps the XFS filesystem on /dev/sda6 to a file. Don't write the >> dump file to the filesystem you're dumping. Preferably the XFS you're >> dumping is on one disk or array and the target file will be written to a >> different disk or array. Dumps are IO intensive. >> >> I clearly stated the "-t" option in the context of xfsrestore: >> >> -t Displays the contents of the dump, but does not create or >> modify any files or directories. It may be desirable to >> set the verbosity level to silent when using this option. >> >> This allows you to do a test run without actually writing any files >> during the restore. The goal here is to test xfsdump and xfsrestore on >> your system to see where errors are cropping up. You don't actually >> want to restore the dumped filesystem at this point. >> >> The "-v" option simply keeps the "-t" from spamming a million file names >> to your console during the restore operation. >> >> -- >> Stan >> >> >>> on 12/4/12 10:32 PM, Stan Hoeppner at stan@hardwarefreak.com wrote: >>> >>>> On 12/4/2012 7:18 PM, J. Ellis wrote: >>>>> Hi, Stan-- >>>>> >>>>> Ok, I truly apologize for my ignorance, but I don't know how to dump the >>>>> contents to a file. Is it something like: >>>>> >>>>> xfsdump -J - somefile_xfsdump.txt >>>> >>>> ~$ man xfsdump >>>> >>>> Look at option "-f". >>>> >>>>> xfsrestore -J - somefile_xfsrestore.txt >>>> >>>> ~$ man xfsrestore >>>> >>>> See options "-f" "-t" and "-v". >>>> >>>> The point of this exercise I believe is to see what errors are thrown by >>>> xfsdump or xfsrestore when they are executed independently, vs through a >>>> pipe. Do note that this may not be the final step in testing before you >>>> have an answer. Post any errors or informational output that results >>>> from these commands. >>>> >>>> Note that the file written by xfsdump is going to be about the same size >>>> as the filesystem being dumped. I.e. if the filesystem being dumped is >>>> 1TB then you need 1TB of free space on the device where the target >>>> directory resides--you're dumping an entire XFS filesystem into a single >>>> file. Also, be sure to use "-t" so xfsrestore doesn't actually write >>>> anything. Did you read "-v"? >> > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <6F909666-9DFE-43F1-973D-170B892F9C5B@gmail.com>]
* Re: xfsdump INTERRUPT issue [not found] ` <6F909666-9DFE-43F1-973D-170B892F9C5B@gmail.com> @ 2012-12-06 9:29 ` Stan Hoeppner 2012-12-06 10:35 ` Jeffrey Ellis 2012-12-07 10:16 ` Dave Chinner 0 siblings, 2 replies; 28+ messages in thread From: Stan Hoeppner @ 2012-12-06 9:29 UTC (permalink / raw) To: Jeffrey Ellis; +Cc: xfs@oss.sgi.com On 12/5/2012 9:01 PM, Jeffrey Ellis wrote: > Ok. > > xfsdump -J -f /xfsdump_file /dev/sda6 / isn't a suitable location to write a dump file. Find a suitable location on another filesystem with enough free space to hold the dump. "xfsdump_file" is an example file name. Use whatever file name you wish. My example XFS filesystem used for illustration purposes resides on /dev/sda6 on one of my machines. /dev/sda6 is probably not the location of the filesystem you are dumping. On what device does your XFS filesystem reside? > xfsrestore -t -v /xfsdump_file Just forget the "-v". It'll make things easier. > Then I post the results? After you get all of the above straightened out. BTW, if your goal in all of this is simply copying all the directories and files from one disk to another disk, you could have used "cp -a" and been done already. It takes longer to execute than xfsdump/xfsrestore, but given you've been at this for many days now, "cp -a" would have already completed--long ago. -- Stan > Best, > J. > > On Dec 5, 2012, at 9:40 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote: > >> On 12/5/2012 8:08 PM, Jeffrey Ellis wrote: >>> Hi, Stan-- >>> >>> You're right. I didn't want to look stupid. Sorry. I'll keep it all on the list from now on. >>> >>> Thank you for the example. I hope I have this right. So including the -t and -v would be >>> >>> ~$ xfsdump -J -f -t -v /xfsdump_file /dev/sda0 >> >> No. That's not right. I gave you concise separate instructions for >> xfsdump and for xfsrestore, and you've commingled the two. >> >> Please thoroughly and thoughtfully re-read my last email. >> >> -- >> Stan >> >> >>> Repeat for each mount point, and post the result here? >>> >>> Thanks again. >>> Jeffrey >>> >>>> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6 >>> >>> >>> >>> Best, >>> J. >>> >>> On Dec 5, 2012, at 8:38 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote: >>> >>>> On 12/5/2012 1:07 PM, J. Ellis wrote: >>>> >>>> This should never have gone off list so I'm copying back. If you'd have >>>> kept this on list you'd have likely already had an answer to this. >>>> Going off list for fear of looking ignorant is not a valid reason to do >>>> so. In fact there are very few reasons to ever go off list. All it >>>> does is take people out of the loop who are watching the thread and may >>>> be willing to jump in at some point to help. You've short circuited >>>> that by going off list. >>>> >>>>> I just read the man page again. There doesn't seem to be any examples I can >>>>> find to write the dump to a file. I couldn't find a -t option in the man at >>>>> all, so maybe the ones I'm finding aren't up to date. Here's the only >>>>> example I can find, and I don't know if this would actually work: >>>>> >>>>> xfsdump -f /usr/tmp/monday_backup -v silent -J -s \ people/fred/Makefile -s >>>>> people/fred/Source /usr >>>> >>>> This is really simple. Using my previous example, we want to dump to a >>>> test file and not update the inventory. So we have something like: >>>> >>>> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6 >>>> >>>> This dumps the XFS filesystem on /dev/sda6 to a file. Don't write the >>>> dump file to the filesystem you're dumping. Preferably the XFS you're >>>> dumping is on one disk or array and the target file will be written to a >>>> different disk or array. Dumps are IO intensive. >>>> >>>> I clearly stated the "-t" option in the context of xfsrestore: >>>> >>>> -t Displays the contents of the dump, but does not create or >>>> modify any files or directories. It may be desirable to >>>> set the verbosity level to silent when using this option. >>>> >>>> This allows you to do a test run without actually writing any files >>>> during the restore. The goal here is to test xfsdump and xfsrestore on >>>> your system to see where errors are cropping up. You don't actually >>>> want to restore the dumped filesystem at this point. >>>> >>>> The "-v" option simply keeps the "-t" from spamming a million file names >>>> to your console during the restore operation. >>>> >>>> -- >>>> Stan >>>> >>>> >>>>> on 12/4/12 10:32 PM, Stan Hoeppner at stan@hardwarefreak.com wrote: >>>>> >>>>>> On 12/4/2012 7:18 PM, J. Ellis wrote: >>>>>>> Hi, Stan-- >>>>>>> >>>>>>> Ok, I truly apologize for my ignorance, but I don't know how to dump the >>>>>>> contents to a file. Is it something like: >>>>>>> >>>>>>> xfsdump -J - somefile_xfsdump.txt >>>>>> >>>>>> ~$ man xfsdump >>>>>> >>>>>> Look at option "-f". >>>>>> >>>>>>> xfsrestore -J - somefile_xfsrestore.txt >>>>>> >>>>>> ~$ man xfsrestore >>>>>> >>>>>> See options "-f" "-t" and "-v". >>>>>> >>>>>> The point of this exercise I believe is to see what errors are thrown by >>>>>> xfsdump or xfsrestore when they are executed independently, vs through a >>>>>> pipe. Do note that this may not be the final step in testing before you >>>>>> have an answer. Post any errors or informational output that results >>>>>> from these commands. >>>>>> >>>>>> Note that the file written by xfsdump is going to be about the same size >>>>>> as the filesystem being dumped. I.e. if the filesystem being dumped is >>>>>> 1TB then you need 1TB of free space on the device where the target >>>>>> directory resides--you're dumping an entire XFS filesystem into a single >>>>>> file. Also, be sure to use "-t" so xfsrestore doesn't actually write >>>>>> anything. Did you read "-v"? >>> >>> _______________________________________________ >>> xfs mailing list >>> xfs@oss.sgi.com >>> http://oss.sgi.com/mailman/listinfo/xfs >> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-06 9:29 ` Stan Hoeppner @ 2012-12-06 10:35 ` Jeffrey Ellis 2012-12-07 10:16 ` Dave Chinner 1 sibling, 0 replies; 28+ messages in thread From: Jeffrey Ellis @ 2012-12-06 10:35 UTC (permalink / raw) To: stan@hardwarefreak.com; +Cc: xfs@oss.sgi.com > / isn't a suitable location to write a dump file. Find a suitable > location on another filesystem with enough free space to hold the dump. > "xfsdump_file" is an example file name. Use whatever file name you wish. That was just an example. > My example XFS filesystem used for illustration purposes resides on > /dev/sda6 on one of my machines. /dev/sda6 is probably not the location > of the filesystem you are dumping. On what device does your XFS > filesystem reside? There are two. /dev/sda0 and /dev/sdb1, IIRC. The first is a blank drive however. >> xfsrestore -t -v /xfsdump_file > > Just forget the "-v". It'll make things easier. So that command is good? > BTW, if your goal in all of this is simply copying all the directories > and files from one disk to another disk, you could have used "cp -a" and > been done already. It takes longer to execute than xfsdump/xfsrestore, > but given you've been at this for many days now, "cp -a" would have > already completed--long ago. No, I wish it was. Best, Jeffrey On Dec 6, 2012, at 4:29 AM, Stan Hoeppner <stan@hardwarefreak.com> wrote: > On 12/5/2012 9:01 PM, Jeffrey Ellis wrote: >> Ok. >> >> xfsdump -J -f /xfsdump_file /dev/sda6 > > / isn't a suitable location to write a dump file. Find a suitable > location on another filesystem with enough free space to hold the dump. > "xfsdump_file" is an example file name. Use whatever file name you wish. > > My example XFS filesystem used for illustration purposes resides on > /dev/sda6 on one of my machines. /dev/sda6 is probably not the location > of the filesystem you are dumping. On what device does your XFS > filesystem reside? > >> xfsrestore -t -v /xfsdump_file > > Just forget the "-v". It'll make things easier. > >> Then I post the results? > > After you get all of the above straightened out. > > BTW, if your goal in all of this is simply copying all the directories > and files from one disk to another disk, you could have used "cp -a" and > been done already. It takes longer to execute than xfsdump/xfsrestore, > but given you've been at this for many days now, "cp -a" would have > already completed--long ago. > > -- > Stan > > >> Best, >> J. >> >> On Dec 5, 2012, at 9:40 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote: >> >>> On 12/5/2012 8:08 PM, Jeffrey Ellis wrote: >>>> Hi, Stan-- >>>> >>>> You're right. I didn't want to look stupid. Sorry. I'll keep it all on the list from now on. >>>> >>>> Thank you for the example. I hope I have this right. So including the -t and -v would be >>>> >>>> ~$ xfsdump -J -f -t -v /xfsdump_file /dev/sda0 >>> >>> No. That's not right. I gave you concise separate instructions for >>> xfsdump and for xfsrestore, and you've commingled the two. >>> >>> Please thoroughly and thoughtfully re-read my last email. >>> >>> -- >>> Stan >>> >>> >>>> Repeat for each mount point, and post the result here? >>>> >>>> Thanks again. >>>> Jeffrey >>>> >>>>> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6 >>>> >>>> >>>> >>>> Best, >>>> J. >>>> >>>> On Dec 5, 2012, at 8:38 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote: >>>> >>>>> On 12/5/2012 1:07 PM, J. Ellis wrote: >>>>> >>>>> This should never have gone off list so I'm copying back. If you'd have >>>>> kept this on list you'd have likely already had an answer to this. >>>>> Going off list for fear of looking ignorant is not a valid reason to do >>>>> so. In fact there are very few reasons to ever go off list. All it >>>>> does is take people out of the loop who are watching the thread and may >>>>> be willing to jump in at some point to help. You've short circuited >>>>> that by going off list. >>>>> >>>>>> I just read the man page again. There doesn't seem to be any examples I can >>>>>> find to write the dump to a file. I couldn't find a -t option in the man at >>>>>> all, so maybe the ones I'm finding aren't up to date. Here's the only >>>>>> example I can find, and I don't know if this would actually work: >>>>>> >>>>>> xfsdump -f /usr/tmp/monday_backup -v silent -J -s \ people/fred/Makefile -s >>>>>> people/fred/Source /usr >>>>> >>>>> This is really simple. Using my previous example, we want to dump to a >>>>> test file and not update the inventory. So we have something like: >>>>> >>>>> ~$ xfsdump -J -f /some_filesystem_path/test_dump /dev/sda6 >>>>> >>>>> This dumps the XFS filesystem on /dev/sda6 to a file. Don't write the >>>>> dump file to the filesystem you're dumping. Preferably the XFS you're >>>>> dumping is on one disk or array and the target file will be written to a >>>>> different disk or array. Dumps are IO intensive. >>>>> >>>>> I clearly stated the "-t" option in the context of xfsrestore: >>>>> >>>>> -t Displays the contents of the dump, but does not create or >>>>> modify any files or directories. It may be desirable to >>>>> set the verbosity level to silent when using this option. >>>>> >>>>> This allows you to do a test run without actually writing any files >>>>> during the restore. The goal here is to test xfsdump and xfsrestore on >>>>> your system to see where errors are cropping up. You don't actually >>>>> want to restore the dumped filesystem at this point. >>>>> >>>>> The "-v" option simply keeps the "-t" from spamming a million file names >>>>> to your console during the restore operation. >>>>> >>>>> -- >>>>> Stan >>>>> >>>>> >>>>>> on 12/4/12 10:32 PM, Stan Hoeppner at stan@hardwarefreak.com wrote: >>>>>> >>>>>>> On 12/4/2012 7:18 PM, J. Ellis wrote: >>>>>>>> Hi, Stan-- >>>>>>>> >>>>>>>> Ok, I truly apologize for my ignorance, but I don't know how to dump the >>>>>>>> contents to a file. Is it something like: >>>>>>>> >>>>>>>> xfsdump -J - somefile_xfsdump.txt >>>>>>> >>>>>>> ~$ man xfsdump >>>>>>> >>>>>>> Look at option "-f". >>>>>>> >>>>>>>> xfsrestore -J - somefile_xfsrestore.txt >>>>>>> >>>>>>> ~$ man xfsrestore >>>>>>> >>>>>>> See options "-f" "-t" and "-v". >>>>>>> >>>>>>> The point of this exercise I believe is to see what errors are thrown by >>>>>>> xfsdump or xfsrestore when they are executed independently, vs through a >>>>>>> pipe. Do note that this may not be the final step in testing before you >>>>>>> have an answer. Post any errors or informational output that results >>>>>>> from these commands. >>>>>>> >>>>>>> Note that the file written by xfsdump is going to be about the same size >>>>>>> as the filesystem being dumped. I.e. if the filesystem being dumped is >>>>>>> 1TB then you need 1TB of free space on the device where the target >>>>>>> directory resides--you're dumping an entire XFS filesystem into a single >>>>>>> file. Also, be sure to use "-t" so xfsrestore doesn't actually write >>>>>>> anything. Did you read "-v"? >>>> >>>> _______________________________________________ >>>> xfs mailing list >>>> xfs@oss.sgi.com >>>> http://oss.sgi.com/mailman/listinfo/xfs >>> >>> _______________________________________________ >>> xfs mailing list >>> xfs@oss.sgi.com >>> http://oss.sgi.com/mailman/listinfo/xfs > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-06 9:29 ` Stan Hoeppner 2012-12-06 10:35 ` Jeffrey Ellis @ 2012-12-07 10:16 ` Dave Chinner 2012-12-07 16:15 ` Jeffrey Ellis 2012-12-07 21:04 ` Stan Hoeppner 1 sibling, 2 replies; 28+ messages in thread From: Dave Chinner @ 2012-12-07 10:16 UTC (permalink / raw) To: Stan Hoeppner; +Cc: Jeffrey Ellis, xfs@oss.sgi.com On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote: > On 12/5/2012 9:01 PM, Jeffrey Ellis wrote: > BTW, if your goal in all of this is simply copying all the directories > and files from one disk to another disk, you could have used "cp -a" and > been done already. It takes longer to execute than xfsdump/xfsrestore, > but given you've been at this for many days now, "cp -a" would have > already completed--long ago. Unfortunately, using cp or rsync is not possible because the filesystem has a real-time device attached to it. It's basically a ~10GB data device and a ~500GB real-time device. I'd say it's from a DVR or something like that, and that Jeffrey is trying to put a bigger disk in the DVR.... Hence there are various DVR forums that suggest xfsdump/xfsrestore is the best method for copying such filesystems to a larger disk. I'd guess that people haven't found xfs_rtcp, or maybe they saw the caveat in the man page(*) and didn't use it.... Cheers, Dave. (*) CAVEATS Currently, realtime partitions are not supported under the Linux version of XFS, and use of a realtime partition WILL CAUSE CORRUPTION on the data partition. As such, this command is made available for curious DEVELOPERS ONLY at this point in time. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-07 10:16 ` Dave Chinner @ 2012-12-07 16:15 ` Jeffrey Ellis 2012-12-07 22:59 ` Dave Chinner 2012-12-07 21:04 ` Stan Hoeppner 1 sibling, 1 reply; 28+ messages in thread From: Jeffrey Ellis @ 2012-12-07 16:15 UTC (permalink / raw) To: Dave Chinner; +Cc: Jeffrey Ellis, Stan Hoeppner, xfs@oss.sgi.com That's it exactly. You mean I could use xfs_rtcp? Best, J. On Dec 7, 2012, at 5:16 AM, Dave Chinner <david@fromorbit.com> wrote: > On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote: >> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote: >> BTW, if your goal in all of this is simply copying all the directories >> and files from one disk to another disk, you could have used "cp -a" and >> been done already. It takes longer to execute than xfsdump/xfsrestore, >> but given you've been at this for many days now, "cp -a" would have >> already completed--long ago. > > Unfortunately, using cp or rsync is not possible because the > filesystem has a real-time device attached to it. It's basically a > ~10GB data device and a ~500GB real-time device. I'd say it's from a > DVR or something like that, and that Jeffrey is trying to put > a bigger disk in the DVR.... > > Hence there are various DVR forums that suggest xfsdump/xfsrestore > is the best method for copying such filesystems to a larger disk. > I'd guess that people haven't found xfs_rtcp, or maybe they saw the > caveat in the man page(*) and didn't use it.... > > Cheers, > > Dave. > > (*) CAVEATS > Currently, realtime partitions are not supported under the > Linux version of XFS, and use of a realtime partition WILL > CAUSE CORRUPTION on the data partition. As such, this command > is made available for curious DEVELOPERS ONLY at this > point in time. > > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-07 16:15 ` Jeffrey Ellis @ 2012-12-07 22:59 ` Dave Chinner 2012-12-07 23:16 ` Jeffrey Ellis 0 siblings, 1 reply; 28+ messages in thread From: Dave Chinner @ 2012-12-07 22:59 UTC (permalink / raw) To: Jeffrey Ellis; +Cc: Jeffrey Ellis, Stan Hoeppner, xfs@oss.sgi.com On Fri, Dec 07, 2012 at 11:15:30AM -0500, Jeffrey Ellis wrote: > That's it exactly. You mean I could use xfs_rtcp? You could, but did you read the caveat and understand what it means? Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-07 22:59 ` Dave Chinner @ 2012-12-07 23:16 ` Jeffrey Ellis 0 siblings, 0 replies; 28+ messages in thread From: Jeffrey Ellis @ 2012-12-07 23:16 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs@oss.sgi.com, Stan Hoeppner, Jeffrey Ellis Gulp. I thought you were suggesting I might still use it in my case. Best, J. On Dec 7, 2012, at 5:59 PM, Dave Chinner <david@fromorbit.com> wrote: > On Fri, Dec 07, 2012 at 11:15:30AM -0500, Jeffrey Ellis wrote: >> That's it exactly. You mean I could use xfs_rtcp? > > You could, but did you read the caveat and understand what it means? > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-07 10:16 ` Dave Chinner 2012-12-07 16:15 ` Jeffrey Ellis @ 2012-12-07 21:04 ` Stan Hoeppner 2012-12-07 22:58 ` Dave Chinner 1 sibling, 1 reply; 28+ messages in thread From: Stan Hoeppner @ 2012-12-07 21:04 UTC (permalink / raw) To: xfs On 12/7/2012 4:16 AM, Dave Chinner wrote: > On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote: >> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote: >> BTW, if your goal in all of this is simply copying all the directories >> and files from one disk to another disk, you could have used "cp -a" and >> been done already. It takes longer to execute than xfsdump/xfsrestore, >> but given you've been at this for many days now, "cp -a" would have >> already completed--long ago. > > Unfortunately, using cp or rsync is not possible because the > filesystem has a real-time device attached to it. It's basically a > ~10GB data device and a ~500GB real-time device. I'd say it's from a > DVR or something like that, and that Jeffrey is trying to put > a bigger disk in the DVR.... Ah, yes. I didn't catch the RT volume. Incidentally, since the real-time feature has never been fully supported under Linux, why are DVR manufacturers even using it? Without GRIO and the XBOW ASIC the real-time volume is pretty much useless isn't it? -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-07 21:04 ` Stan Hoeppner @ 2012-12-07 22:58 ` Dave Chinner 2012-12-07 23:26 ` Stan Hoeppner 0 siblings, 1 reply; 28+ messages in thread From: Dave Chinner @ 2012-12-07 22:58 UTC (permalink / raw) To: Stan Hoeppner; +Cc: xfs On Fri, Dec 07, 2012 at 03:04:57PM -0600, Stan Hoeppner wrote: > On 12/7/2012 4:16 AM, Dave Chinner wrote: > > On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote: > >> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote: > >> BTW, if your goal in all of this is simply copying all the directories > >> and files from one disk to another disk, you could have used "cp -a" and > >> been done already. It takes longer to execute than xfsdump/xfsrestore, > >> but given you've been at this for many days now, "cp -a" would have > >> already completed--long ago. > > > > Unfortunately, using cp or rsync is not possible because the > > filesystem has a real-time device attached to it. It's basically a > > ~10GB data device and a ~500GB real-time device. I'd say it's from a > > DVR or something like that, and that Jeffrey is trying to put > > a bigger disk in the DVR.... > > Ah, yes. I didn't catch the RT volume. > > Incidentally, since the real-time feature has never been fully supported > under Linux, why are DVR manufacturers even using it? Without GRIO and > the XBOW ASIC the real-time volume is pretty much useless isn't it? The realtime volume actually has nothing to do with "real-time" at all. What it has is a deterministic allocator (bitmap rather than tree based) which is what you need for real-time applications (i.e. bound worst case performance). It got called the "real-time device" because of the applications it was used for, not because there is anything "real-time" about it. IOWs, you don't need special hardware to take advantage of the properties of the allocator. DVR manufacturers have decided to use it for 3 reasons: 1. Folklore says you need a RT device for concurrent streaming workloads 2. It's supported upstream 3. It makes it hard for windows users to replace the harddisk in the DVR by themselves (true). #3 is the case we are seeing here. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-07 22:58 ` Dave Chinner @ 2012-12-07 23:26 ` Stan Hoeppner 2012-12-08 1:31 ` Dave Chinner 0 siblings, 1 reply; 28+ messages in thread From: Stan Hoeppner @ 2012-12-07 23:26 UTC (permalink / raw) To: xfs On 12/7/2012 4:58 PM, Dave Chinner wrote: > On Fri, Dec 07, 2012 at 03:04:57PM -0600, Stan Hoeppner wrote: >> On 12/7/2012 4:16 AM, Dave Chinner wrote: >>> On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote: >>>> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote: >>>> BTW, if your goal in all of this is simply copying all the directories >>>> and files from one disk to another disk, you could have used "cp -a" and >>>> been done already. It takes longer to execute than xfsdump/xfsrestore, >>>> but given you've been at this for many days now, "cp -a" would have >>>> already completed--long ago. >>> >>> Unfortunately, using cp or rsync is not possible because the >>> filesystem has a real-time device attached to it. It's basically a >>> ~10GB data device and a ~500GB real-time device. I'd say it's from a >>> DVR or something like that, and that Jeffrey is trying to put >>> a bigger disk in the DVR.... >> >> Ah, yes. I didn't catch the RT volume. >> >> Incidentally, since the real-time feature has never been fully supported >> under Linux, why are DVR manufacturers even using it? Without GRIO and >> the XBOW ASIC the real-time volume is pretty much useless isn't it? > > The realtime volume actually has nothing to do with "real-time" at > all. What it has is a deterministic allocator (bitmap rather than > tree based) which is what you need for real-time applications (i.e. > bound worst case performance). It got called the "real-time device" > because of the applications it was used for, not because there is > anything "real-time" about it. IOWs, you don't need special > hardware to take advantage of the properties of the allocator. > > DVR manufacturers have decided to use it for 3 reasons: > > 1. Folklore says you need a RT device for > concurrent streaming workloads > 2. It's supported upstream Define "support" and "upstream". The few RT related posts over the past years generated responses, some from you I think, that the RT code isn't maintained, hasn't been for a long time. Maybe I've misunderstood. > 3. It makes it hard for windows users to replace the > harddisk in the DVR by themselves (true). > > #3 is the case we are seeing here. Yes this seems to be the case. > Cheers, > > Dave. > -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-07 23:26 ` Stan Hoeppner @ 2012-12-08 1:31 ` Dave Chinner 0 siblings, 0 replies; 28+ messages in thread From: Dave Chinner @ 2012-12-08 1:31 UTC (permalink / raw) To: Stan Hoeppner; +Cc: xfs On Fri, Dec 07, 2012 at 05:26:12PM -0600, Stan Hoeppner wrote: > On 12/7/2012 4:58 PM, Dave Chinner wrote: > > On Fri, Dec 07, 2012 at 03:04:57PM -0600, Stan Hoeppner wrote: > >> On 12/7/2012 4:16 AM, Dave Chinner wrote: > >>> On Thu, Dec 06, 2012 at 03:29:33AM -0600, Stan Hoeppner wrote: > >>>> On 12/5/2012 9:01 PM, Jeffrey Ellis wrote: > >>>> BTW, if your goal in all of this is simply copying all the directories > >>>> and files from one disk to another disk, you could have used "cp -a" and > >>>> been done already. It takes longer to execute than xfsdump/xfsrestore, > >>>> but given you've been at this for many days now, "cp -a" would have > >>>> already completed--long ago. > >>> > >>> Unfortunately, using cp or rsync is not possible because the > >>> filesystem has a real-time device attached to it. It's basically a > >>> ~10GB data device and a ~500GB real-time device. I'd say it's from a > >>> DVR or something like that, and that Jeffrey is trying to put > >>> a bigger disk in the DVR.... > >> > >> Ah, yes. I didn't catch the RT volume. > >> > >> Incidentally, since the real-time feature has never been fully supported > >> under Linux, why are DVR manufacturers even using it? Without GRIO and > >> the XBOW ASIC the real-time volume is pretty much useless isn't it? > > > > The realtime volume actually has nothing to do with "real-time" at > > all. What it has is a deterministic allocator (bitmap rather than > > tree based) which is what you need for real-time applications (i.e. > > bound worst case performance). It got called the "real-time device" > > because of the applications it was used for, not because there is > > anything "real-time" about it. IOWs, you don't need special > > hardware to take advantage of the properties of the allocator. > > > > DVR manufacturers have decided to use it for 3 reasons: > > > > 1. Folklore says you need a RT device for > > concurrent streaming workloads > > 2. It's supported upstream > > Define "support" and "upstream". The few RT related posts over the past > years generated responses, some from you I think, that the RT code isn't > maintained, hasn't been for a long time. Maybe I've misunderstood. We've found that over the past few years that there have been a lot of "silent users". While we don't actively develop/improve the RT functionality, maintenance still takes place. That is, we take they patches for the bugs users find and we try not to introduce new bugs as we change stuff. And I do run xfstests with realtime devices every so often - it's just not a high priority. IOWs, if a vendor wants to ship a product based on the real-time functionality, then that is their choice. It is also their responsibility to ensure what they ship is fit for purpose, which is why they have their own QA.... :) Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* xfsdump INTERRUPT issue
@ 2012-12-01 16:03 J. Ellis
2012-12-01 17:39 ` Jeffrey Ellis
2012-12-02 21:10 ` Dave Chinner
0 siblings, 2 replies; 28+ messages in thread
From: J. Ellis @ 2012-12-01 16:03 UTC (permalink / raw)
To: xfs@oss.sgi.com
[-- Attachment #1.1: Type: text/plain, Size: 997 bytes --]
I'm trying to prepare a question regarding an xfsdump INTERRUPT error I'm
getting, and I'm trying to follow the guidelines for reporting such issues
here:
http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_r
eporting_a_problem.3F
But these last two instructions I'm having a problem finding the information
on how to generate:
xfs_info output on the filesystem in question (I tried xfs_info /dev/sdc,
but it keeps saying for each drive that it's not a mounted xfs system IIRC)
dmesg output showing all error messages and stack traces
Then you need to describe your workload that is causing the problem, and a
demonstration of the bad behavior that is occurring. If it is a performance
problem, then 30s - 1 minute samples of:
1. iostat -x -d -m 5
2. vmstat 5
Do I run this simultaneously while xfstools are working? I'm also not sure
what's meant by describe your workload. Can someone step me through this?
Please excuse my n00bness.
Best,
Jeffrey
[-- Attachment #1.2: Type: text/html, Size: 1699 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: xfsdump INTERRUPT issue 2012-12-01 16:03 J. Ellis @ 2012-12-01 17:39 ` Jeffrey Ellis 2012-12-02 1:40 ` Stan Hoeppner 2012-12-02 21:10 ` Dave Chinner 1 sibling, 1 reply; 28+ messages in thread From: Jeffrey Ellis @ 2012-12-01 17:39 UTC (permalink / raw) To: xfs@oss.sgi.com [-- Attachment #1.1: Type: text/plain, Size: 1333 bytes --] Anyone? Or do I have enough to ask the question? Best, J. On Dec 1, 2012, at 11:03 AM, "J. Ellis" <jellis@dhnet.us> wrote: > I'm trying to prepare a question regarding an xfsdump INTERRUPT error I'm getting, and I'm trying to follow the guidelines for reporting such issues here: > > http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F > > But these last two instructions I'm having a problem finding the information on how to generate: > > > xfs_info output on the filesystem in question (I tried xfs_info /dev/sdc, but it keeps saying for each drive that it's not a mounted xfs system IIRC) > > dmesg output showing all error messages and stack traces > > Then you need to describe your workload that is causing the problem, and a demonstration of the bad behavior that is occurring. If it is a performance problem, then 30s - 1 minute samples of: > 1. iostat -x -d -m 5 > 2. vmstat 5 > > > Do I run this simultaneously while xfstools are working? I'm also not sure what's meant by describe your workload. Can someone step me through this? > > Please excuse my n00bness. > > Best, > Jeffrey > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs [-- Attachment #1.2: Type: text/html, Size: 2365 bytes --] [-- Attachment #2: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-01 17:39 ` Jeffrey Ellis @ 2012-12-02 1:40 ` Stan Hoeppner 2012-12-03 16:49 ` J. Ellis 0 siblings, 1 reply; 28+ messages in thread From: Stan Hoeppner @ 2012-12-02 1:40 UTC (permalink / raw) To: xfs On 12/1/2012 11:39 AM, Jeffrey Ellis wrote: > Anyone? > > Or do I have enough to ask the question? We aren't the US Govt, i.e. we're not going to ignore your help request just because you're missing a few details. They may not be relevant anyway. So ask away with the details you do have. If anything else is needed we'll ask you to provide it. -- Stan > Best, > J. > > On Dec 1, 2012, at 11:03 AM, "J. Ellis" <jellis@dhnet.us> wrote: > >> I'm trying to prepare a question regarding an xfsdump INTERRUPT error I'm getting, and I'm trying to follow the guidelines for reporting such issues here: >> >> http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F >> >> But these last two instructions I'm having a problem finding the information on how to generate: >> >> >> xfs_info output on the filesystem in question (I tried xfs_info /dev/sdc, but it keeps saying for each drive that it's not a mounted xfs system IIRC) >> >> dmesg output showing all error messages and stack traces >> >> Then you need to describe your workload that is causing the problem, and a demonstration of the bad behavior that is occurring. If it is a performance problem, then 30s - 1 minute samples of: >> 1. iostat -x -d -m 5 >> 2. vmstat 5 >> >> >> Do I run this simultaneously while xfstools are working? I'm also not sure what's meant by describe your workload. Can someone step me through this? >> >> Please excuse my n00bness. >> >> Best, >> Jeffrey >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-02 1:40 ` Stan Hoeppner @ 2012-12-03 16:49 ` J. Ellis 2012-12-03 21:34 ` Dave Chinner 2012-12-04 19:46 ` J. Ellis 0 siblings, 2 replies; 28+ messages in thread From: J. Ellis @ 2012-12-03 16:49 UTC (permalink / raw) To: stan, Dave Chinner; +Cc: xfs@oss.sgi.com Thank you to Stan and Dave for helping me through this. Ok, here's the file, printed below. Basically, I'm running the following commands under Ubuntu 12.10: Type mkdir /mnt/fp Type mkdir /mnt/hr20 Type mount -t xfs -o rtdev=/dev/sda3 /dev/sda2 /mnt/fp Type mount -t xfs -o rtdev=/dev/sdb3 /dev/sdb2 /mnt/hr20 Type xfsdump -J - /mnt/hr20 | xfsrestore -J - /mnt/fp When run, I get this as my output: xfsdump: WARNING: write to stdio failed: 32 (Broken pipe) xfsdump: ending media file xfsdump: media file size 18874368 bytes xfsdump: dump size (non-dir files) : 13698056 bytes xfsdump: NOTE: dump interrupted: 16 seconds elapsed xfsdump: Dump Status: INTERRUPT This happens each time. In the forum where this copy procedure was suggested, they've been reporting that the latest xfsprogs is creating these errors, which didn't happen under at least somewhat earlier versions. The version of xfsprogs should be in the file, but it was just downloaded a few days ago using git. Best, Jeffrey xfs requested data file: kernel version: Linux jeffrey 3.5.0-18-generic #29-Ubuntu SMP Fri Oct 19 10:27:31 UTC 2012 i686 i686 i686 GNU/Linux xfsprogs version: xfs_repair version 3.1.8 number of CPU's: 8 contents of /proc/meminfo: MemTotal: 6184324 kB MemFree: 4986560 kB Buffers: 32036 kB Cached: 446368 kB SwapCached: 0 kB Active: 680296 kB Inactive: 402548 kB Active(anon): 612444 kB Inactive(anon): 368 kB Active(file): 67852 kB Inactive(file): 402180 kB Unevictable: 32596 kB Mlocked: 32596 kB HighTotal: 5365768 kB HighFree: 4264648 kB LowTotal: 818556 kB LowFree: 721912 kB SwapTotal: 1023996 kB SwapFree: 1023996 kB Dirty: 1484 kB Writeback: 0 kB AnonPages: 637224 kB Mapped: 148540 kB Shmem: 1284 kB Slab: 36908 kB SReclaimable: 16864 kB SUnreclaim: 20044 kB KernelStack: 3664 kB PageTables: 8296 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 4116156 kB Committed_AS: 3172256 kB VmallocTotal: 122880 kB VmallocUsed: 13156 kB VmallocChunk: 104244 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 8184 kB DirectMap2M: 905216 kB contents of /proc/mounts: rootfs / rootfs rw 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 udev /dev devtmpfs rw,relatime,size=3084428k,nr_inodes=200772,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,relatime,size=1236868k,mode=755 0 0 /dev/disk/by-uuid/e33b147d-faaa-4e55-8f3b-2fb2d3168053 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 none /sys/fs/fuse/connections fusectl rw,relatime 0 0 none /sys/kernel/debug debugfs rw,relatime 0 0 none /sys/kernel/security securityfs rw,relatime 0 0 none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0 none /run/user tmpfs rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755 0 0 gvfsd-fuse /run/user/jeffrey/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0 contents of /proc/partitions: major minor #blocks name 11 0 1048575 sr0 8 0 1953514584 sda 8 1 530113 sda1 8 2 15735664 sda2 8 3 1937246216 sda3 8 16 488386584 sdb 8 17 530113 sdb1 8 18 15735664 sdb2 8 19 472118216 sdb3 8 32 1953514584 sdc 8 33 1024000 sdc1 8 34 1952489258 sdc2 11 1 1048575 sr1 RAID Layout: no Raid LVM Configuration: Sorry, I didn't have the education to get this information. Type of discs: 2 3.5² SATA drives, 1 half-height SATA. hdparm results: /dev/sda: ATA device, with non-removable media Model Number: Hitachi HDS723020BLA642 Serial Number: MN1240FA04NWHD Firmware Revision: MN6OA800 Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6; Revision: ATA8-AST T13 Project D1697 Revision 0b Standards: Used: unknown (minor revision code 0x0029) Supported: 8 7 6 5 Likely used: 8 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 3907029168 Logical Sector size: 512 bytes Physical Sector size: 512 bytes device size with M = 1024*1024: 1907729 MBytes device size with M = 1000*1000: 2000398 MBytes (2000 GB) cache/buffer size = unknown Form Factor: 3.5 inch Nominal Media Rotation Rate: 7200 Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 0 Advanced power management level: disabled DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set * Write cache * Look-ahead * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command * NOP cmd * DOWNLOAD_MICROCODE Advanced Power Management feature set Power-Up In Standby feature set * SET_FEATURES required to spinup after power up * SET_MAX security extension * 48-bit Address feature set * Device Configuration Overlay feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test Media Card Pass-Through * General Purpose Logging feature set * WRITE_{DMA|MULTIPLE}_FUA_EXT * 64-bit World wide name * URG for READ_STREAM[_DMA]_EXT * URG for WRITE_STREAM[_DMA]_EXT * WRITE_UNCORRECTABLE_EXT command * {READ,WRITE}_DMA_EXT_GPL commands * Segmented DOWNLOAD_MICROCODE unknown 119[7] * Gen1 signaling speed (1.5Gb/s) * Gen2 signaling speed (3.0Gb/s) * Gen3 signaling speed (6.0Gb/s) * Native Command Queueing (NCQ) * Host-initiated interface power management * Phy event counters * NCQ priority information Non-Zero buffer offsets in DMA Setup FIS DMA Setup Auto-Activate optimization Device-initiated interface power management In-order data delivery * Software settings preservation * SMART Command Transport (SCT) feature set * SCT LBA Segment Access (AC2) * SCT Error Recovery Control (AC3) * SCT Features Control (AC4) * SCT Data Tables (AC5) Security: Master password revision code = 65534 supported not enabled not locked frozen not expired: security count not supported: enhanced erase 420min for SECURITY ERASE UNIT. Logical Unit WWN Device Identifier: 5000cca36ac21fe4 NAA : 5 IEEE OUI : 000cca Unique ID : 36ac21fe4 Checksum: correct /dev/sdb: ATA device, with non-removable media Model Number: ST3500312CS Serial Number: 6VV60HXR Firmware Revision: SC13 Transport: Serial Standards: Used: unknown (minor revision code 0x0029) Supported: 8 7 6 5 Likely used: 8 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 976773168 Logical/Physical Sector size: 512 bytes device size with M = 1024*1024: 476940 MBytes device size with M = 1000*1000: 500107 MBytes (500 GB) cache/buffer size = 8192 KBytes Nominal Media Rotation Rate: 5900 Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = ? Advanced power management level: 254 Recommended acoustic management value: 254, current value: 0 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set * Write cache * Look-ahead * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command * DOWNLOAD_MICROCODE * Advanced Power Management feature set Power-Up In Standby feature set SET_FEATURES required to spinup after power up * SET_MAX security extension * 48-bit Address feature set * Device Configuration Overlay feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test * Media Card Pass-Through * General Purpose Logging feature set * 64-bit World wide name Write-Read-Verify feature set * WRITE_UNCORRECTABLE_EXT command * {READ,WRITE}_DMA_EXT_GPL commands * Segmented DOWNLOAD_MICROCODE * Gen1 signaling speed (1.5Gb/s) * Gen2 signaling speed (3.0Gb/s) * Native Command Queueing (NCQ) * Phy event counters Device-initiated interface power management * Software settings preservation * SMART Command Transport (SCT) feature set * SCT Long Sector Access (AC1) * SCT Error Recovery Control (AC3) * SCT Features Control (AC4) * SCT Data Tables (AC5) unknown 206[12] (vendor specific) Security: Master password revision code = 65534 supported not enabled not locked frozen not expired: security count supported: enhanced erase 100min for SECURITY ERASE UNIT. 100min for ENHANCED SECURITY ERASE UNIT. Logical Unit WWN Device Identifier: 5000c500307c5d66 NAA : 5 IEEE OUI : 000c50 Unique ID : 0307c5d66 Checksum: correct /dev/sdc: ATA device, with non-removable media Model Number: Hitachi HDS723020BLA642 Serial Number: MN3220F32KR53E Firmware Revision: MN6OA800 Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6; Revision: ATA8-AST T13 Project D1697 Revision 0b Standards: Used: unknown (minor revision code 0x0029) Supported: 8 7 6 5 Likely used: 8 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 3907029168 Logical Sector size: 512 bytes Physical Sector size: 512 bytes device size with M = 1024*1024: 1907729 MBytes device size with M = 1000*1000: 2000398 MBytes (2000 GB) cache/buffer size = unknown Form Factor: 3.5 inch Nominal Media Rotation Rate: 7200 Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 0 Advanced power management level: disabled DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set * Write cache * Look-ahead * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command * NOP cmd * DOWNLOAD_MICROCODE Advanced Power Management feature set Power-Up In Standby feature set * SET_FEATURES required to spinup after power up * SET_MAX security extension * 48-bit Address feature set * Device Configuration Overlay feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test Media Card Pass-Through * General Purpose Logging feature set * WRITE_{DMA|MULTIPLE}_FUA_EXT * 64-bit World wide name * URG for READ_STREAM[_DMA]_EXT * URG for WRITE_STREAM[_DMA]_EXT * WRITE_UNCORRECTABLE_EXT command * {READ,WRITE}_DMA_EXT_GPL commands * Segmented DOWNLOAD_MICROCODE unknown 119[7] * Gen1 signaling speed (1.5Gb/s) * Gen2 signaling speed (3.0Gb/s) * Gen3 signaling speed (6.0Gb/s) * Native Command Queueing (NCQ) * Host-initiated interface power management * Phy event counters * NCQ priority information Non-Zero buffer offsets in DMA Setup FIS DMA Setup Auto-Activate optimization Device-initiated interface power management In-order data delivery * Software settings preservation * SMART Command Transport (SCT) feature set * SCT LBA Segment Access (AC2) * SCT Error Recovery Control (AC3) * SCT Features Control (AC4) * SCT Data Tables (AC5) Security: Master password revision code = 65534 supported not enabled not locked frozen not expired: security count not supported: enhanced erase 456min for SECURITY ERASE UNIT. Logical Unit WWN Device Identifier: 5000cca369e43c85 NAA : 5 IEEE OUI : 000cca Unique ID : 369e43c85 Checksum: correct Size of BBWC and Mode: Again, sorry, I couldn't find how to get this. xfs_info: root@jeffrey:~# xfs_info /mnt/fp meta-data=/dev/sda2 isize=256 agcount=16, agsize=245869 blks = sectsz=512 attr=0 data = bsize=4096 blocks=3933904, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =external extsz=1048576 blocks=484311554, rtextents=1891842 root@jeffrey:~# xfs_info /mnt/hr20 meta-data=/dev/sdb2 isize=256 agcount=16, agsize=245869 blks = sectsz=512 attr=0 data = bsize=4096 blocks=3933904, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =external extsz=1048576 blocks=118029554, rtextents=461052 _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-03 16:49 ` J. Ellis @ 2012-12-03 21:34 ` Dave Chinner 2012-12-03 22:27 ` Jeffrey Ellis 2012-12-04 19:46 ` J. Ellis 1 sibling, 1 reply; 28+ messages in thread From: Dave Chinner @ 2012-12-03 21:34 UTC (permalink / raw) To: J. Ellis; +Cc: stan, xfs@oss.sgi.com On Mon, Dec 03, 2012 at 11:49:46AM -0500, J. Ellis wrote: > Thank you to Stan and Dave for helping me through this. > > Ok, here's the file, printed below. > > Basically, I'm running the following commands under Ubuntu 12.10: > > Type mkdir /mnt/fp > Type mkdir /mnt/hr20 > Type mount -t xfs -o rtdev=/dev/sda3 /dev/sda2 /mnt/fp > Type mount -t xfs -o rtdev=/dev/sdb3 /dev/sdb2 /mnt/hr20 > Type xfsdump -J - /mnt/hr20 | xfsrestore -J - /mnt/fp > > When run, I get this as my output: > > xfsdump: WARNING: write to stdio failed: 32 (Broken pipe) FWIW, this implies that xfsrestore failed. What is the output from xfsrestore? Can you just run xfsdump to a file? Also, the dmesg output is missing - can you attach it? Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-03 21:34 ` Dave Chinner @ 2012-12-03 22:27 ` Jeffrey Ellis 2012-12-05 0:32 ` Stan Hoeppner 0 siblings, 1 reply; 28+ messages in thread From: Jeffrey Ellis @ 2012-12-03 22:27 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs@oss.sgi.com, stan@hardwarefreak.com, J. Ellis Hi, Dave-- > FWIW, this implies that xfsrestore failed. What is the output from > xfsrestore? Can you just run xfsdump to a file? Can you tell me how to do that and dmesg? Best, J. On Dec 3, 2012, at 4:34 PM, Dave Chinner <david@fromorbit.com> wrote: > On Mon, Dec 03, 2012 at 11:49:46AM -0500, J. Ellis wrote: >> Thank you to Stan and Dave for helping me through this. >> >> Ok, here's the file, printed below. >> >> Basically, I'm running the following commands under Ubuntu 12.10: >> >> Type mkdir /mnt/fp >> Type mkdir /mnt/hr20 >> Type mount -t xfs -o rtdev=/dev/sda3 /dev/sda2 /mnt/fp >> Type mount -t xfs -o rtdev=/dev/sdb3 /dev/sdb2 /mnt/hr20 >> Type xfsdump -J - /mnt/hr20 | xfsrestore -J - /mnt/fp >> >> When run, I get this as my output: >> >> xfsdump: WARNING: write to stdio failed: 32 (Broken pipe) > > FWIW, this implies that xfsrestore failed. What is the output from > xfsrestore? Can you just run xfsdump to a file? > > Also, the dmesg output is missing - can you attach it? > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-03 22:27 ` Jeffrey Ellis @ 2012-12-05 0:32 ` Stan Hoeppner 2012-12-05 1:18 ` J. Ellis 0 siblings, 1 reply; 28+ messages in thread From: Stan Hoeppner @ 2012-12-05 0:32 UTC (permalink / raw) To: xfs On 12/3/2012 4:27 PM, Jeffrey Ellis wrote: xfs_info output and this below is all that is needed at this point. >> FWIW, this implies that xfsrestore failed. What is the output from >> xfsrestore? Can you just run xfsdump to a file? > Can you tell me how to do that and dmesg? The command you posted xfsdump -J - /mnt/hr20 | xfsrestore -J - /mnt/fp pipes the output from xfsdump into xfsrestore. This error xfsdump: WARNING: write to stdio failed: 32 (Broken pipe) tells us something broke while piping into xfsrestore, possibly xfsrestore itself. I believe what Dave is asking you is to xfsdump to a file, then xfsrestore that file. In two separate operations. This should tell us more about where the problem is. Regarding dmesg information, simply do ~$ dmesg and copy the output into your email. It should be a few screen fulls starting with something like: Linux version 3.2.6 (root@greer) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Mon Feb 20 17:05:10 CST 2012 WRT xfs_info: ~$ cat /etc/mtab ... /dev/sda6 /home xfs rw 0 0 ... ~$ xfs_info /dev/sda6 meta-data=/dev/sda6 isize=256 agcount=4, agsize=6103694 blks = sectsz=512 attr=2 data = bsize=4096 blocks=24414775, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=11921, version=2 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-05 0:32 ` Stan Hoeppner @ 2012-12-05 1:18 ` J. Ellis 2012-12-05 3:32 ` Stan Hoeppner 0 siblings, 1 reply; 28+ messages in thread From: J. Ellis @ 2012-12-05 1:18 UTC (permalink / raw) To: stan, xfs Hi, Stan-- Ok, I truly apologize for my ignorance, but I don't know how to dump the contents to a file. Is it something like: xfsdump -J - somefile_xfsdump.txt xfsrestore -J - somefile_xfsrestore.txt ? Best, J. on 12/4/12 7:32 PM, Stan Hoeppner at stan@hardwarefreak.com wrote: > On 12/3/2012 4:27 PM, Jeffrey Ellis wrote: > > xfs_info output and this below is all that is needed at this point. > >>> FWIW, this implies that xfsrestore failed. What is the output from >>> xfsrestore? Can you just run xfsdump to a file? > >> Can you tell me how to do that and dmesg? > > The command you posted > > xfsdump -J - /mnt/hr20 | xfsrestore -J - /mnt/fp > > pipes the output from xfsdump into xfsrestore. This error > > xfsdump: WARNING: write to stdio failed: 32 (Broken pipe) > > tells us something broke while piping into xfsrestore, possibly > xfsrestore itself. I believe what Dave is asking you is to xfsdump to a > file, then xfsrestore that file. In two separate operations. This > should tell us more about where the problem is. > > Regarding dmesg information, simply do > > ~$ dmesg > > and copy the output into your email. It should be a few screen fulls > starting with something like: > > Linux version 3.2.6 (root@greer) (gcc version 4.4.5 (Debian 4.4.5-8) ) > #1 SMP Mon Feb 20 17:05:10 CST 2012 > > WRT xfs_info: > > ~$ cat /etc/mtab > ... > /dev/sda6 /home xfs rw 0 0 > ... > > ~$ xfs_info /dev/sda6 > meta-data=/dev/sda6 isize=256 agcount=4, agsize=6103694 blks > = sectsz=512 attr=2 > data = bsize=4096 blocks=24414775, imaxpct=25 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0 > log =internal bsize=4096 blocks=11921, version=2 > = sectsz=512 sunit=0 blks, lazy-count=0 > realtime =none extsz=4096 blocks=0, rtextents=0 > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-05 1:18 ` J. Ellis @ 2012-12-05 3:32 ` Stan Hoeppner 0 siblings, 0 replies; 28+ messages in thread From: Stan Hoeppner @ 2012-12-05 3:32 UTC (permalink / raw) To: xfs On 12/4/2012 7:18 PM, J. Ellis wrote: > Hi, Stan-- > > Ok, I truly apologize for my ignorance, but I don't know how to dump the > contents to a file. Is it something like: > > xfsdump -J - somefile_xfsdump.txt ~$ man xfsdump Look at option "-f". > xfsrestore -J - somefile_xfsrestore.txt ~$ man xfsrestore See options "-f" "-t" and "-v". The point of this exercise I believe is to see what errors are thrown by xfsdump or xfsrestore when they are executed independently, vs through a pipe. Do note that this may not be the final step in testing before you have an answer. Post any errors or informational output that results from these commands. Note that the file written by xfsdump is going to be about the same size as the filesystem being dumped. I.e. if the filesystem being dumped is 1TB then you need 1TB of free space on the device where the target directory resides--you're dumping an entire XFS filesystem into a single file. Also, be sure to use "-t" so xfsrestore doesn't actually write anything. Did you read "-v"? -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-03 16:49 ` J. Ellis 2012-12-03 21:34 ` Dave Chinner @ 2012-12-04 19:46 ` J. Ellis 2012-12-04 22:56 ` Stan Hoeppner 1 sibling, 1 reply; 28+ messages in thread From: J. Ellis @ 2012-12-04 19:46 UTC (permalink / raw) To: Jeffrey Ellis, stan, Dave Chinner; +Cc: xfs@oss.sgi.com Hi, Dave & Stan, et al-- Are you guys getting this post? I don't see it showing up on the list and have had no responses. I'm wondering if the size of the text of the requested xfs info I had added is causing an issue getting it posted. If not, here's a repost, using a link to the file instead. http://dhnet.us/xfs/xfs_data_file.odt Best, Jeffrey on 12/3/12 11:49 AM, Jeffrey Ellis at jellis@dhnet.us wrote: > Thank you to Stan and Dave for helping me through this. > > Ok, here's the file, printed below. > > Basically, I'm running the following commands under Ubuntu 12.10: > > Type mkdir /mnt/fp > Type mkdir /mnt/hr20 > Type mount -t xfs -o rtdev=/dev/sda3 /dev/sda2 /mnt/fp > Type mount -t xfs -o rtdev=/dev/sdb3 /dev/sdb2 /mnt/hr20 > Type xfsdump -J - /mnt/hr20 | xfsrestore -J - /mnt/fp > > When run, I get this as my output: > > xfsdump: WARNING: write to stdio failed: 32 (Broken pipe) > xfsdump: ending media file > xfsdump: media file size 18874368 bytes > xfsdump: dump size (non-dir files) : 13698056 bytes > xfsdump: NOTE: dump interrupted: 16 seconds elapsed > xfsdump: Dump Status: INTERRUPT > > This happens each time. In the forum where this copy procedure was > suggested, they've been reporting that the latest xfsprogs is creating these > errors, which didn't happen under at least somewhat earlier versions. > > The version of xfsprogs should be in the file, but it was just downloaded a > few days ago using git. > > Best, > Jeffrey _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-04 19:46 ` J. Ellis @ 2012-12-04 22:56 ` Stan Hoeppner 2012-12-04 23:07 ` Jeffrey Ellis 0 siblings, 1 reply; 28+ messages in thread From: Stan Hoeppner @ 2012-12-04 22:56 UTC (permalink / raw) To: J. Ellis; +Cc: xfs@oss.sgi.com On 12/4/2012 1:46 PM, J. Ellis wrote: > Hi, Dave & Stan, et al-- > > Are you guys getting this post? I don't see it showing up on the list and > have had no responses. I'm wondering if the size of the text of the > requested xfs info I had added is causing an issue getting it posted. You need to acclimate yourself to the environment/culture of FLOSS mailing lists. First, don't be giddy. Responses to users will rarely be immediate. People, both devs and fellow users, contribute help on an "as time permits" basis. You are not paying for support here. I've seen some msgs go unanswered for a week or more, both initial requests and follow ups. I short, don't expect rapid responses and individual hand holding. > If not, here's a repost, using a link to the file instead. > > http://dhnet.us/xfs/xfs_data_file.odt Regarding what you think may be lost mail, using an office document format is not wise, though I don't know if it's allowed here or not. In general, with FLOSS lists, use plain text, always, whether inline or attachment. Try not to reference external links as this list is archived by many sites. Get it all in the archives. Finally, if you sent me a direct email and my server rejected it you would receive an NDR pretty quickly. And I don't see any msgs from you in my spam tagged folder. -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-04 22:56 ` Stan Hoeppner @ 2012-12-04 23:07 ` Jeffrey Ellis 2012-12-05 22:19 ` Dave Chinner 0 siblings, 1 reply; 28+ messages in thread From: Jeffrey Ellis @ 2012-12-04 23:07 UTC (permalink / raw) To: stan@hardwarefreak.com; +Cc: xfs@oss.sgi.com Hi, Stan-- Ah, sorry. I actually tried sending it to you, Dave and the list by attachment and by including the text in the email. So it looks like this is the only way it got through. Should I try reposting a version with just the text again? Best, J. On Dec 4, 2012, at 5:56 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote: > On 12/4/2012 1:46 PM, J. Ellis wrote: >> Hi, Dave & Stan, et al-- >> >> Are you guys getting this post? I don't see it showing up on the list and >> have had no responses. I'm wondering if the size of the text of the >> requested xfs info I had added is causing an issue getting it posted. > > You need to acclimate yourself to the environment/culture of FLOSS > mailing lists. First, don't be giddy. Responses to users will rarely > be immediate. People, both devs and fellow users, contribute help on an > "as time permits" basis. You are not paying for support here. I've > seen some msgs go unanswered for a week or more, both initial requests > and follow ups. I short, don't expect rapid responses and individual > hand holding. > >> If not, here's a repost, using a link to the file instead. >> >> http://dhnet.us/xfs/xfs_data_file.odt > > Regarding what you think may be lost mail, using an office document > format is not wise, though I don't know if it's allowed here or not. In > general, with FLOSS lists, use plain text, always, whether inline or > attachment. Try not to reference external links as this list is > archived by many sites. Get it all in the archives. > > Finally, if you sent me a direct email and my server rejected it you > would receive an NDR pretty quickly. And I don't see any msgs from you > in my spam tagged folder. > > -- > Stan > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-04 23:07 ` Jeffrey Ellis @ 2012-12-05 22:19 ` Dave Chinner 0 siblings, 0 replies; 28+ messages in thread From: Dave Chinner @ 2012-12-05 22:19 UTC (permalink / raw) To: Jeffrey Ellis; +Cc: stan@hardwarefreak.com, xfs@oss.sgi.com On Tue, Dec 04, 2012 at 06:07:38PM -0500, Jeffrey Ellis wrote: > Hi, Stan-- > > Ah, sorry. > > I actually tried sending it to you, Dave and the list by > attachment and by including the text in the email. So it looks > like this is the only way it got through. Should I try reposting a > version with just the text again? No, please don't. Everything you have sent has got through. If you really, want to know if something got through to the list, go an look at the list archives on one of the many list archive sites availble. e.g. here's the entire thread: http://marc.info/?t=135437797000003&r=1&w=2 Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-01 16:03 J. Ellis 2012-12-01 17:39 ` Jeffrey Ellis @ 2012-12-02 21:10 ` Dave Chinner 2012-12-02 21:16 ` Jeffrey Ellis 1 sibling, 1 reply; 28+ messages in thread From: Dave Chinner @ 2012-12-02 21:10 UTC (permalink / raw) To: J. Ellis; +Cc: xfs@oss.sgi.com On Sat, Dec 01, 2012 at 11:03:57AM -0500, J. Ellis wrote: > I'm trying to prepare a question regarding an xfsdump INTERRUPT error I'm > getting, and I'm trying to follow the guidelines for reporting such issues > here: > > http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_r > eporting_a_problem.3F > > But these last two instructions I'm having a problem finding the information > on how to generate: > > > xfs_info output on the filesystem in question (I tried xfs_info /dev/sdc, > but it keeps saying for each drive that it's not a mounted xfs system IIRC) $ man xfs_info .... xfs_info [ -t mtab ] mount-point .... > dmesg output showing all error messages and stack traces Run the dmesg command.... > Then you need to describe your workload that is causing the problem, and a > demonstration of the bad behavior that is occurring. If it is a performance > problem, then 30s - 1 minute samples of: > 1. iostat -x -d -m 5 > 2. vmstat 5 > > > Do I run this simultaneously while xfstools are working? I'm also not sure > what's meant by describe your workload. Can someone step me through this? Do you have a performance problem? I don't think you have - your problem is that xfsdump is failing for some reason - so this information is unnecessary. As to your workload, your problem is xfsdump is failing for some reason. Hence we need to know roughly what xfsdump is running on. i.e. describe the directory structure/filesystem contents being backed up.... BTW, don't expect responses to questions in a hour late on friday night/weekends - if you are lucky someone will be in front of their computer over a weekend, sometimes you are not so lucky... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: xfsdump INTERRUPT issue 2012-12-02 21:10 ` Dave Chinner @ 2012-12-02 21:16 ` Jeffrey Ellis 0 siblings, 0 replies; 28+ messages in thread From: Jeffrey Ellis @ 2012-12-02 21:16 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs@oss.sgi.com Ah :) Ok, I'll skip dmesg and add xfs_info. And I'll make sure to post everything Monday. Thanks again :) Best, J. On Dec 2, 2012, at 4:10 PM, Dave Chinner <david@fromorbit.com> wrote: > On Sat, Dec 01, 2012 at 11:03:57AM -0500, J. Ellis wrote: >> I'm trying to prepare a question regarding an xfsdump INTERRUPT error I'm >> getting, and I'm trying to follow the guidelines for reporting such issues >> here: >> >> http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_r >> eporting_a_problem.3F >> >> But these last two instructions I'm having a problem finding the information >> on how to generate: >> >> >> xfs_info output on the filesystem in question (I tried xfs_info /dev/sdc, >> but it keeps saying for each drive that it's not a mounted xfs system IIRC) > > $ man xfs_info > .... > xfs_info [ -t mtab ] mount-point > .... > >> dmesg output showing all error messages and stack traces > > Run the dmesg command.... > >> Then you need to describe your workload that is causing the problem, and a >> demonstration of the bad behavior that is occurring. If it is a performance >> problem, then 30s - 1 minute samples of: >> 1. iostat -x -d -m 5 >> 2. vmstat 5 >> >> >> Do I run this simultaneously while xfstools are working? I'm also not sure >> what's meant by describe your workload. Can someone step me through this? > > Do you have a performance problem? I don't think you have - your problem is > that xfsdump is failing for some reason - so this information is > unnecessary. > > As to your workload, your problem is xfsdump is failing for some > reason. Hence we need to know roughly what xfsdump is running on. > i.e. describe the directory structure/filesystem contents being > backed up.... > > BTW, don't expect responses to questions in a hour late on friday > night/weekends - if you are lucky someone will be in front of their > computer over a weekend, sometimes you are not so lucky... > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2012-12-08 1:28 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CCE505AA.B05B7%jellis@dhnet.us>
2012-12-06 1:38 ` xfsdump INTERRUPT issue Stan Hoeppner
2012-12-06 2:08 ` Jeffrey Ellis
2012-12-06 2:40 ` Stan Hoeppner
[not found] ` <6F909666-9DFE-43F1-973D-170B892F9C5B@gmail.com>
2012-12-06 9:29 ` Stan Hoeppner
2012-12-06 10:35 ` Jeffrey Ellis
2012-12-07 10:16 ` Dave Chinner
2012-12-07 16:15 ` Jeffrey Ellis
2012-12-07 22:59 ` Dave Chinner
2012-12-07 23:16 ` Jeffrey Ellis
2012-12-07 21:04 ` Stan Hoeppner
2012-12-07 22:58 ` Dave Chinner
2012-12-07 23:26 ` Stan Hoeppner
2012-12-08 1:31 ` Dave Chinner
2012-12-01 16:03 J. Ellis
2012-12-01 17:39 ` Jeffrey Ellis
2012-12-02 1:40 ` Stan Hoeppner
2012-12-03 16:49 ` J. Ellis
2012-12-03 21:34 ` Dave Chinner
2012-12-03 22:27 ` Jeffrey Ellis
2012-12-05 0:32 ` Stan Hoeppner
2012-12-05 1:18 ` J. Ellis
2012-12-05 3:32 ` Stan Hoeppner
2012-12-04 19:46 ` J. Ellis
2012-12-04 22:56 ` Stan Hoeppner
2012-12-04 23:07 ` Jeffrey Ellis
2012-12-05 22:19 ` Dave Chinner
2012-12-02 21:10 ` Dave Chinner
2012-12-02 21:16 ` Jeffrey Ellis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox