RE: xfs Digest, Vol 29, Issue 102

RE: xfs Digest, Vol 29, Issue 102

[lord worm]

[-- Attachment #1.1: Type: text/plain, Size: 10865 bytes --]


Stan, do you check dates on links before you paste them here? I don't care if its the 1st results of the google search 'meaning of life', its irrelevant and oudated.

> From: xfs-request@oss.sgi.com
> Subject: xfs Digest, Vol 29, Issue 102
> To: xfs@oss.sgi.com
> Date: Sun, 30 Jan 2011 21:49:14 -0600
> 
> Send xfs mailing list submissions to
> 	xfs@oss.sgi.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://oss.sgi.com/mailman/listinfo/xfs
> or, via email, send a message with subject or body 'help' to
> 	xfs-request@oss.sgi.com
> 
> You can reach the person managing the list at
> 	xfs-owner@oss.sgi.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of xfs digest..."
> 
> 
> Today's Topics:
> 
>    1. RE: xfs Digest, Vol 29, Issue 101 (lord worm)
>    2. Re: xfs Digest, Vol 29, Issue 101 (Stan Hoeppner)
>    3. Re: [patch] xfsprogs: repair pagefault due to missed out
>       sanity NULL	check (Ajeet Yadav)
>    4. Re: [patch] xfsprogs: repair never return if device removed
>       (Ajeet Yadav)
>    5. Re: how to decode metadump info produced by xfs_db, and
>       superblock	error (Dave Chinner)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sun, 30 Jan 2011 13:27:51 -0500
> From: lord worm <cryptopsy@live.com>
> Subject: RE: xfs Digest, Vol 29, Issue 101
> To: <xfs@oss.sgi.com>
> Message-ID: <SNT130-w7320373265265D515EDD5DAE30@phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 
> Stan I have no idea, could you tell me in detail why dd failed, and what exactly those restore commands provide specifically?
> 
>  		 	   		  
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://oss.sgi.com/pipermail/xfs/attachments/20110130/dee98fcc/attachment-0001.htm>
> 
> ------------------------------
> 
> Message: 2
> Date: Sun, 30 Jan 2011 15:03:42 -0600
> From: Stan Hoeppner <stan@hardwarefreak.com>
> Subject: Re: xfs Digest, Vol 29, Issue 101
> To: xfs@oss.sgi.com
> Message-ID: <4D45D22E.2060603@hardwarefreak.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> lord worm put forth on 1/30/2011 12:27 PM:
> > 
> > Stan I have no idea, could you tell me in detail why dd failed, and what exactly those restore commands provide specifically?
> 
> This might have some relevance.  2nd hit Googling for "dd with xfs":
> 
> http://oss.sgi.com/archives/xfs/2003-04/msg00802.html
> 
> -- 
> Stan
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 31 Jan 2011 11:39:15 +0900
> From: Ajeet Yadav <ajeet.yadav.77@gmail.com>
> Subject: Re: [patch] xfsprogs: repair pagefault due to missed out
> 	sanity NULL	check
> To: xfs@oss.sgi.com
> Message-ID:
> 	<AANLkTinK25hL3Ljy42S6KrqEJ7nW_L+c77GPJhBVo=58@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> I did not receive any response / review comment on solution patch I sent.
> 
> diff -Nurp xfsprogs/repair/dir2.c xfsprogs-dirty/repair/dir2.c
> 
> --- xfsprogs/repair/dir2.c 2010-07-16 13:07:09.000000000 +0900
> 
> +++ xfsprogs-dirty/repair/dir2.c 2011-01-28 18:49:21.000000000 +0900
> 
> @@ -110,9 +110,10 @@ da_read_buf(
> 
> bplist[i] = libxfs_readbuf(mp->m_dev,
> 
> XFS_FSB_TO_DADDR(mp, bmp[i].startblock),
> 
> XFS_FSB_TO_BB(mp, bmp[i].blockcount), 0);
> 
> - if (!bplist[i])
> 
> + if (!bplist[i]){
> 
> + nex = i;
> 
> goto failed;
> 
> -
> 
> + }
> 
> pftrace("readbuf %p (%llu, %d)", bplist[i],
> 
> (long long)XFS_BUF_ADDR(bplist[i]),
> 
> XFS_BUF_COUNT(bplist[i]));
> On Fri, Jan 28, 2011 at 8:13 PM, Ajeet Yadav <ajeet.yadav.77@gmail.com>wrote:
> 
> > libxfs_putbuf() is called with bp = NULL, resulting in pagefault in
> > libpthread.
> >
> > Function da_read_buf() allocate array of xfs_buf_t *
> >
> >    * xfs_buf_t       **bplist;*
> >
> > *    bplist = calloc(nex, sizeof(*bplist));*
> >
> > Read and fill it using
> >
> > *for (i = 0; i < nex; i++) {
> >     bplist[i] = libxfs_readbuf()*
> >
> > *    if (!bplist[i]){
> >         goto failed;
> >     }  *
> >
> > *}*
> >
> > *failed:
> >         for (i = 0; i < nex; i++)
> >                 libxfs_putbuf(bplist[i]);*
> >
> > Now assume nex = 10,
> >
> > 1. Will create bplist for 10 array elements.
> >
> > 3. Reading from disk 0,1, 2, 3
> >
> > 4. When reading from disk 4, USB is removed
> >
> > 5. libxfs_readbuf() will at fail, pblist[4] = NULL, goto failed.
> >
> > 6. Since only 4 buffers were read successfully, so only 4 are in lock
> > state.
> >
> > 7.  Error handling will unlock buffer from 1-10
> >
> > 8. Buffer 0-3 were read successfully, hence will have valid pdlist[i]
> >
> > 9. Access pblist[4] == NULL, therefore unlocking will set bp == NULL in
> > libxfs_putbuf(bp);
> > 10. Page fault in libpthread
> >
> >
> > Solution patch attached with mail
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://oss.sgi.com/pipermail/xfs/attachments/20110131/4e2718ae/attachment-0001.htm>
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 31 Jan 2011 11:41:16 +0900
> From: Ajeet Yadav <ajeet.yadav.77@gmail.com>
> Subject: Re: [patch] xfsprogs: repair never return if device removed
> To: xfs@oss.sgi.com
> Message-ID:
> 	<AANLkTikyOfkbtxN3Et5YZRJ2rPpdsVouJkyRW4fDbUG7@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> I did not receive and response / reviews on patch.
> 
> diff -Nurp xfsprogs/repair/sb.c xfsprogs-dirty/repair/sb.c
> 
> --- xfsprogs/repair/sb.c 2011-01-28 20:23:02.000000000 +0900
> 
> +++ xfsprogs-dirty/repair/sb.c 2011-01-28 20:21:06.000000000 +0900
> 
> @@ -122,8 +122,9 @@ find_secondary_sb(xfs_sb_t *rsb)
> 
> done = 1;
> 
> }
> 
> - if (!done && (bsize = read(x.dfd, sb, BSIZE)) == 0) {
> 
> + if (!done && (bsize = read(x.dfd, sb, BSIZE)) <= 0) {
> 
> done = 1;
> 
> + do_warn(_("Couldn't find candidate secondary superblock, exiting...\n"));
> 
> }
> 
> do_warn(".");
> 
> On Fri, Jan 28, 2011 at 8:31 PM, Ajeet Yadav <ajeet.yadav.77@gmail.com>wrote:
> 
> > xfsprogs all version, delete primary superblock of xfs partition
> >
> > dd if=/dev/zero of=/dev/sda1 bs=512 count=1
> > sync
> >
> > Run xfs_repair in partition, while its searching for secondary superblock,
> > remove the disk (USB) xfs_repair will never exit and will loop in never
> > ending ............
> >
> > Please find patch attached with mail
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://oss.sgi.com/pipermail/xfs/attachments/20110131/77ad227f/attachment-0001.htm>
> 
> ------------------------------
> 
> Message: 5
> Date: Mon, 31 Jan 2011 14:51:31 +1100
> From: Dave Chinner <david@fromorbit.com>
> Subject: Re: how to decode metadump info produced by xfs_db, and
> 	superblock	error
> To: lord worm <cryptopsy@live.com>
> Cc: xfs@oss.sgi.com
> Message-ID: <20110131035131.GI21311@dastard>
> Content-Type: text/plain; charset=us-ascii
> 
> On Sun, Jan 30, 2011 at 08:21:19PM -0500, lord worm wrote:
> > > Date: Mon, 31 Jan 2011 08:40:26 +1100
> > > From: david@fromorbit.com
> > > To: cryptopsy@live.com
> > > Subject: Re: how to decode metadump info produced by xfs_db, and superblock error
> > > 
> > > On Sun, Jan 30, 2011 at 11:33:53AM -0500, lord worm wrote:
> > > > > Date: Sun, 30 Jan 2011 18:16:30 +1100
> > > > > From: david@fromorbit.com
> > > > > To: cryptopsy@live.com
> > > > > CC: xfs@oss.sgi.com
> > > > > Subject: Re: how to decode metadump info produced by xfs_db, and superblock error
> > > > > 
> > > > > On Sat, Jan 29, 2011 at 07:25:10PM -0500, lord worm wrote:
> > > > > > 
> > > > > > What kind of information is in this file produced by metadump, is it worth reading it somehow?
> > > > > > 
> > > > > > I'm trying to first understand what's causing a 'superblock cannot
> > > > > > be read' error in my XFS after a succesfully dd of the partition
> > > > > > (dd succeeds in copying to a file, and also restoring, but after
> > > > > > restoring it cannot mount).
> > > > > 
> > > > > dmesg output when the mount fails?
> > > > 
> > > > Could you email the mailing list next time as well, so that my
> > > > forwards are directed towards everyone, please?
> > > 
> > > I did:
> > > 
> > > http://oss.sgi.com/archives/xfs/2011-01/msg00486.html
> > > 
> > > As for list ettiquette - please don't top post and wrap all you text
> > > except for code and pasted log messages at 72 columns.....
> 
> Fixed that for you again.
> 
> > > > Here's dmesg from the backup file, but I don't have it from the original disk after restoring it:
> > > > 
> > > > [  362.685464] attempt to access beyond end of device
> > > > [  362.685468] loop5: rw=0, want=15662872, limit=15661056
> > > > [  362.685473] I/O error in filesystem ("loop5") meta-data dev loop5 block 0xeeff17       ("xfs_read_buf") error 5 buf count 512
> > > > [  362.685478] XFS: size check 2 failed
> > > 
> > > Simple problem - you copied the filesystem back onto a device that
> > > is too small for the filesystem.
> > 
> > When I reply to this email, it defaults to david@fromorbit.com, so
> > how will the others see it?
> 
> Reply to all. It's common courtesy to reply to everyone on the
> cc-list for mailing list traffic as it often contains people not
> subscribed to the mailing list (e.g. a person reporting a bug).
> 
> I've added the xfs list back onto the cc-list.
> 
> > I can't mount the direct dd image of the drive as a loop device
> > either by the same error.
> 
> Which means you probably didn't copy the entire drive in the first
> place.
> 
> > The error persists even when its not
> > the filesystem that was copied back onto the device. Additionally,
> > its the exact same device with the exact same partition type
> > created by the exact same version of disk.
> 
> partition type doesn't matter - the size does. The above error
> indicates that the loop device is 1816 sectors (908kiB) shorter than
> it needs to be, so maybe you aren't recreating the partition as
> large as it needs to be, too....
> 
> As it is, the question I have at this point is why are you trying to
> copy the filesystem via dd? if all you want is an image, xfs_copy is
> probably what you want....
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 
> 
> End of xfs Digest, Vol 29, Issue 102
> ************************************
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 13472 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfs Digest, Vol 29, Issue 102

[Stan Hoeppner]

lord worm put forth on 1/30/2011 10:41 PM:

> Stan, do you check dates on links before you paste them here? I don't care if its the 1st results of the google search 'meaning of life', its irrelevant and oudated.

At the time I sent that reply, you had posted no log information, nothing
concrete to allow us to focus our troubleshooting efforts.  At that time, the
information in the link I provided could have been as relevant as any other.  At
that time I had not seen the off list back-n-forth between you and Dave that
contained a little bit more information from you.  Note that I said "might be
relevant", not "this is your answer".

Note that Dave recently pointed an OP to a 1996 XFS paper.  Some information in
that 15 year old paper is still relevant today.  You cannot simply discard
information because it appears "old" to you.  Some aspects of XFS haven't
changed in 16 years.

As I said in my first response, xfsdump/xfsrestore would have avoided your
current problem, as well as xfs_copy, as Dave pointed out.

There is nothing set in stone that prevents dd from working with XFS
filesystems.  However, it is obviously less forgiving of error, user or
otherwise, than the 'equivalent' XFS utilities.

Lastly, getting testy with those attempting to assist you isn't going to further
your efforts in fixing your problem.

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs