linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stan Hoeppner <stan@hardwarefreak.com>
To: Aaron Scheiner <blue@aquarat.za.net>
Cc: NeilBrown <neilb@suse.de>, linux-raid@vger.kernel.org
Subject: Re: Grub-install, superblock corrupted/erased and other animals
Date: Tue, 02 Aug 2011 11:41:25 -0500	[thread overview]
Message-ID: <4E3828B5.2050202@hardwarefreak.com> (raw)
In-Reply-To: <CADz4AWFJHah=OkZ0JaC8ZZD+E13D6tOvhz7cRR0oc19OfsOQew@mail.gmail.com>

On 8/2/2011 11:24 AM, Aaron Scheiner wrote:
> wow... I had no idea XFS was that complex, great for performance,
> horrible for file recovery :P . Thanks for the explanation.
> 
> Based on this the scalpel+lots of samples approach might not work...
> I'll investigate XFS a little more closely, I just assumed it would
> write big files in one continuous block.

Maybe I didn't completely understand what you're trying to do...

As long as there is enough free space within an AG, any newly created
file will be written contiguously (from the FS POV).  If you have 15
extent AGs and write 30 of these files, 2 will be written into each AG.
 There will be lots of free space between the last file in AG2 and AG3,
on down the line.  When I said the data would not be contiguous, I was
referring to the overall composition of the filesystem, not individual
files.  Depending on their size, individual files will be broken up
into, what, 128KB chunks, and spread across the 8 disk stripe, by mdraid.

> This makes a lot of sense; I reconstructed/re-created the array using
> a random drive order, scalpel'ed the md device for the start of the
> video file and found it. I then dd'ed that out to a file on the hard
> drive and then loaded that into a hex editor. The file ended abruptly
> after about +/-384KBs. I couldn't find any other data belonging to the
> file within 50MBs around the the sample scalpel had found.

What is the original size of this video file?

> Thanks again for the info.

Sure thing.  Hope you get it going.

-- 
Stan

  reply	other threads:[~2011-08-02 16:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-27 12:16 Grub-install, superblock corrupted/erased and other animals Aaron Scheiner
2011-08-02  6:39 ` NeilBrown
2011-08-02  8:01   ` Stan Hoeppner
2011-08-02 16:24     ` Aaron Scheiner
2011-08-02 16:41       ` Stan Hoeppner [this message]
2011-08-02 21:13         ` Aaron Scheiner
2011-08-03  4:02           ` Stan Hoeppner
2011-08-02 16:16   ` Aaron Scheiner
2011-08-03  5:01     ` NeilBrown
2011-08-03  8:59       ` Aaron Scheiner
2011-08-03  9:20         ` NeilBrown
2011-08-05 10:04           ` Aaron Scheiner
2011-08-05 10:32             ` Stan Hoeppner
2011-08-05 11:28               ` Aaron Scheiner
2011-08-05 12:16                 ` NeilBrown
2011-08-03  7:13 ` Stan Hoeppner

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=4E3828B5.2050202@hardwarefreak.com \
    --to=stan@hardwarefreak.com \
    --cc=blue@aquarat.za.net \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).