From: Eric Sandeen <sandeen@sandeen.net>
To: Brian Foster <bfoster@redhat.com>, Eric Sandeen <sandeen@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 03/13] xfs_db: add crc manipulation commands
Date: Fri, 20 Mar 2015 21:30:13 -0500 [thread overview]
Message-ID: <550CD7B5.8030507@sandeen.net> (raw)
In-Reply-To: <20150319150755.GC11669@laptop.bfoster>
On 3/19/15 10:07 AM, Brian Foster wrote:
> On Tue, Mar 17, 2015 at 03:33:05PM -0500, Eric Sandeen wrote:
>> This adds a new "crc" command to xfs_db for CRC-enabled filesystems.
...
if (argc) while ((c = getopt(argc, argv, "irv")) != EOF) {
>
> The 'if (argc)' thing strikes again. Does this address something I'm not
> aware of?
just a dumb/unfortunate cut & paste from elsewhere, I'll fix.
...
>> + /* Off by one.. */
>> + crc = cpu_to_be32(crc + 1);
>> + setbitval(iocur_top->data, sfl->offset, bit_length, &crc);
>
> Some comments on the above code would be nice to explain what it's
> calculating.
Yeah, wish I'd written them "yonks ago" ;) I'll reverse engineer my
patch & add comments.
>> + dbprintf(_("Verifying CRC:\n"));
>
> Does the "verify" aspect of this command do anything, or are we just
> printing the state that was determined from a previous cursor load? If
> the latter, I wonder if it's worth retaining that option (e.g., just
> print an inode to see the crc state)..?
If having a specific CRC handler makes sense (and, maybe it doesn't,
with the other patch that allows corrupted write), the symmetry seemed
nice.
Given the amount of code this adds, perhaps we should just drop it,
TBH, and use the "write -c" functionality I added, instead.
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-03-21 2:30 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-17 20:33 [PATCH 00/13] xfsprogs: roll-up of previously sent patches Eric Sandeen
2015-03-17 20:33 ` [PATCH 01/13] xfs_db: Allow writes of corrupted data by optionally skipping write verifiers Eric Sandeen
2015-03-19 15:07 ` Brian Foster
2015-03-23 20:00 ` [PATCH 01/13 V2] " Eric Sandeen
2015-03-24 12:07 ` Brian Foster
2015-03-17 20:33 ` [PATCH 02/13] xfs_db: fix inode CRC validity state, and warn on read if invalid Eric Sandeen
2015-03-19 15:07 ` Brian Foster
2015-03-21 2:26 ` Eric Sandeen
2015-03-21 14:18 ` Brian Foster
2015-03-23 20:11 ` [PATCH 02/13 V2] " Eric Sandeen
2015-03-24 12:07 ` Brian Foster
2015-03-17 20:33 ` [PATCH 03/13] xfs_db: add crc manipulation commands Eric Sandeen
2015-03-19 15:07 ` Brian Foster
2015-03-21 2:30 ` Eric Sandeen [this message]
2015-03-21 14:18 ` Brian Foster
2015-03-23 20:01 ` [PATCH 03/13 DROP] " Eric Sandeen
2015-03-17 20:33 ` [PATCH 04/13] xfs_db: nlink fields are valid for di_version == 3, too Eric Sandeen
2015-03-17 20:33 ` [PATCH 05/13] xfs_repair: dirty inode in process_sf_dir2 if we change namelen Eric Sandeen
2015-03-17 20:33 ` [PATCH 06/13] xfs_repair: remove impossible tests in process_sf_dir2 Eric Sandeen
2015-03-17 20:33 ` [PATCH 07/13] xfs_repair: collapse 2 cases " Eric Sandeen
2015-03-17 20:33 ` [PATCH 08/13] xfs_repair: remove last-entry hack " Eric Sandeen
2015-03-17 20:33 ` [PATCH 09/13] libxfs: remove ASSERT on ftype read from disk Eric Sandeen
2015-03-19 16:46 ` Brian Foster
2015-03-19 17:27 ` Eric Sandeen
2015-03-23 20:13 ` PATCH 09/13 V2] " Eric Sandeen
2015-03-24 12:07 ` Brian Foster
2015-03-17 20:33 ` [PATCH 10/13] xfs_repair: clear need_root_dotdot if we rebuild the root dir Eric Sandeen
2015-03-17 20:33 ` [PATCH 11/13] xfs_repair: set *parent if process_dir2_data() fixes root inode Eric Sandeen
2015-03-17 20:33 ` [PATCH 12/13] xfs_repair: don't clear . or .. in process_dir2_data Eric Sandeen
2015-03-19 16:47 ` Brian Foster
2015-03-19 17:29 ` Eric Sandeen
2015-03-19 17:54 ` Brian Foster
2015-03-19 17:59 ` Eric Sandeen
2015-03-19 18:07 ` Brian Foster
2015-03-23 20:17 ` [PATCH 12/13 V2] " Eric Sandeen
2015-03-24 12:07 ` Brian Foster
2015-03-17 20:33 ` [PATCH 13/13] xfs_repair: validate & fix inode CRCs Eric Sandeen
2015-03-19 16:47 ` Brian Foster
2015-03-23 20:19 ` [PATCH 13/13 V2] " Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=550CD7B5.8030507@sandeen.net \
--to=sandeen@sandeen.net \
--cc=bfoster@redhat.com \
--cc=sandeen@redhat.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox