|
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@xxxxxxxxxxx > Subject: xfs Digest, Vol 29, Issue 102 > To: xfs@xxxxxxxxxxx > Date: Sun, 30 Jan 2011 21:49:14 -0600 > > Send xfs mailing list submissions to > xfs@xxxxxxxxxxx > > 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@xxxxxxxxxxx > > You can reach the person managing the list at > xfs-owner@xxxxxxxxxxx > > 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@xxxxxxxx> > Subject: RE: xfs Digest, Vol 29, Issue 101 > To: <xfs@xxxxxxxxxxx> > Message-ID: <SNT130-w7320373265265D515EDD5DAE30@xxxxxxx> > 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@xxxxxxxxxxxxxxxxx> > Subject: Re: xfs Digest, Vol 29, Issue 101 > To: xfs@xxxxxxxxxxx > Message-ID: <4D45D22E.2060603@xxxxxxxxxxxxxxxxx> > 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@xxxxxxxxx> > Subject: Re: [patch] xfsprogs: repair pagefault due to missed out > sanity NULL check > To: xfs@xxxxxxxxxxx > Message-ID: > <AANLkTinK25hL3Ljy42S6KrqEJ7nW_L+c77GPJhBVo=58@xxxxxxxxxxxxxx> > 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@xxxxxxxxx>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@xxxxxxxxx> > Subject: Re: [patch] xfsprogs: repair never return if device removed > To: xfs@xxxxxxxxxxx > Message-ID: > <AANLkTikyOfkbtxN3Et5YZRJ2rPpdsVouJkyRW4fDbUG7@xxxxxxxxxxxxxx> > 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@xxxxxxxxx>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@xxxxxxxxxxxxx> > Subject: Re: how to decode metadump info produced by xfs_db, and > superblock error > To: lord worm <cryptopsy@xxxxxxxx> > Cc: xfs@xxxxxxxxxxx > 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@xxxxxxxxxxxxx > > > To: cryptopsy@xxxxxxxx > > > 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@xxxxxxxxxxxxx > > > > > To: cryptopsy@xxxxxxxx > > > > > CC: xfs@xxxxxxxxxxx > > > > > 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@xxxxxxxxxxxxx, 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@xxxxxxxxxxxxx > > > > ------------------------------ > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs > > > End of xfs Digest, Vol 29, Issue 102 > ************************************ |
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
