non mountable xfs with 2 primary and 2 logical

non mountable xfs with 2 primary and 2 logical

[Richard Waterbeek]

Hi linux-xfs mailinglist,

I've recently subscribed to this list. I've seen many messages, but have
little understading of the 'XFS' file system. I know about mkfs.xfs.
I've benched my hardware. But, now my harddrive had a collision with the
mbr somehow. [or something]

But, now I've 'hexdumped', the first 512 bytes, [because after a
disaterous reboot, cfdisk is now saying; "/dev/sda empty".

I'm aware of two primary and two logical partitions. I feel that I know
the size of the first and second primary, but the xfs/ sda5 and, xfs
sda6, are no longer appearing. I had to '#' the /etc/fstab, because it
won't boot [long waiting].

Now I would like to restore the first 512 bytes which is the MBR.

I have absolutely no understanding of -where-, "the SuperBlock" [or how
that should be called], happens to be.

But, I feel that 512 bytes missing and no reason to believe a whole
Terabyte would be "ones and/ or zero's", now, I wonder, how to restore
this. I have not made backup of this harddrive, just an rsync, which is
a little outdated and a bit incomplete, because difference in size of
both drives.

I might be able to create a XFS-something [from /dev/sda, for example],
and write that with dd. 

But, before I would 'try this out', I would like to gain some
understanding, of what -should- be on the first 512 bytes of a
harddrive, besides what I have now, cfdisk is saying empty.

Hoping to receive a reply, Richard, the Netherlands

Re: non mountable xfs with 2 primary and 2 logical

[Eric Sandeen]

On 6/28/17 4:43 PM, Richard Waterbeek wrote:
> Hi linux-xfs mailinglist,
> 
> I've recently subscribed to this list. I've seen many messages, but have
> little understading of the 'XFS' file system. I know about mkfs.xfs.
> I've benched my hardware. But, now my harddrive had a collision with the
> mbr somehow. [or something]
> 
> But, now I've 'hexdumped', the first 512 bytes, [because after a
> disaterous reboot, cfdisk is now saying; "/dev/sda empty".

If the xfs partition you lost was on extended partition sda5,
that's not at the front of the disk.  It sounds like something
overwrote your partition table. 

Honestly, recreating a partition table isn't an xfs issue.

> I'm aware of two primary and two logical partitions. I feel that I know
> the size of the first and second primary, but the xfs/ sda5 and, xfs
> sda6, are no longer appearing. I had to '#' the /etc/fstab, because it
> won't boot [long waiting].
> 
> Now I would like to restore the first 512 bytes which is the MBR.
> 
> I have absolutely no understanding of -where-, "the SuperBlock" [or how
> that should be called], happens to be.

The MBR is not the XFS superblock.  sda5's XFS superblock is somewhere
much further into the disk.

I don't think anyone here can tell you how to recreate the partitions,
because nobody knows what their exact size was.
 
The XFS superblock signature is "XFSB" so you could go hexdumping the
whole disk, look for eveny-spaced occurences of that pattern, and assume
that you've found some superblocks, and work backwards from there.

All this is essentially data recovery, getting well beyond the scope of
normal mailing-list help, though.

-Eric

> But, I feel that 512 bytes missing and no reason to believe a whole
> Terabyte would be "ones and/ or zero's", now, I wonder, how to restore
> this. I have not made backup of this harddrive, just an rsync, which is
> a little outdated and a bit incomplete, because difference in size of
> both drives.
> 
> I might be able to create a XFS-something [from /dev/sda, for example],
> and write that with dd. 
> 
> But, before I would 'try this out', I would like to gain some
> understanding, of what -should- be on the first 512 bytes of a
> harddrive, besides what I have now, cfdisk is saying empty.
> 
> Hoping to receive a reply, Richard, the Netherlands
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: non mountable xfs with 2 primary and 2 logical

[Richard Waterbeek]

Hello Eric, linux-xfs list,

I have been thinking about getting myself options first.

I learned that;

The [Linux] operating system, doesn't recognize all "sda<number>"
partition. But I have found a program "CG TestDisk". To avoid discuccins
about that program, let me post a link to a screenshot, of what I have
now.

First things first, the two NTFS partitions have been restored.

Then, I expect to find a 'sda5', and a 'sda6', [so that is an extended
partition, containing two XFS partitions [524GB and 363GB]. 

The first screenshot is this program, again, to avoid discussing about
that program, [CG TestDisk], my question is related to XFS. Because; I
can tell, there seems to be a 'drive geometry', readable.

Here is the link to the screenshot;
http://www.fotobakje.nl/map/div/linux/testdisk/testdisk-correcte-weergave.png [Notice the two green 'L']. However, it is reported as being 'HPFS/ NTFS'.

Now I wonder about the geometry, is it possible [and how], to calculate
where mkfs.xfs, should have been written something [this is based on my
expectations, I really have no real understanding of the XFS file
system], so, where mkfs.xfs should have been written a [sda5 "mbr"],
since I believe the SuperBlock or SuperBlocks are intact. Since you
might have noticed there are five partitions in total [NTFS/ NTFS/ EXT4/
XFS/ XFS], I wonder, is there a way, I make a call to the [most]
knowledgable people here, to have a "xfs-<something", program or another
way, to learn, -where-, "mkfs.xfs", should "find" [I actually mean where
Linux expects an 'sda/ xfs block', to -mount- those file systems.

This I ask [I know it is a bit complicated, trying to learn here],
because; xfs_repair expects a mounted file system [ro]. And, with
"guessing", and writing with mkfs.xfs which is easy for me to do, I can
be almost sure, I will end up with an empty XFS file system. [Yes, the
damaged drive, is still untouched by me], reading NTFS wasn't a pain.

I sincerely hope to get some waypointers, that will help me in my -own-
search. Please do not tell me this isn't XFS related. It is XFS related,
it might just be my person, willing and trying to be able, to understand
XFS and where that [I expect 512 bytes sector, not a "mkfs.xfs
recreation [that will make it bust for for sure], or if I am mistaken,
please tell me about the options you are thinking of. I of course take
full responsibillity for the steps I make [e.g. a real write to this
hard drive], so no one to blame, if it fails somehow.

Richard.




Eric Sandeen schreef op wo 28-06-2017 om 16:52 [-0500]:
> On 6/28/17 4:43 PM, Richard Waterbeek wrote:
> > Hi linux-xfs mailinglist,
> > 
> > I've recently subscribed to this list. I've seen many messages, but have
> > little understading of the 'XFS' file system. I know about mkfs.xfs.
> > I've benched my hardware. But, now my harddrive had a collision with the
> > mbr somehow. [or something]
> > 
> > But, now I've 'hexdumped', the first 512 bytes, [because after a
> > disaterous reboot, cfdisk is now saying; "/dev/sda empty".
> 
> If the xfs partition you lost was on extended partition sda5,
> that's not at the front of the disk.  It sounds like something
> overwrote your partition table. 
> 
> Honestly, recreating a partition table isn't an xfs issue.
> 
> > I'm aware of two primary and two logical partitions. I feel that I know
> > the size of the first and second primary, but the xfs/ sda5 and, xfs
> > sda6, are no longer appearing. I had to '#' the /etc/fstab, because it
> > won't boot [long waiting].
> > 
> > Now I would like to restore the first 512 bytes which is the MBR.
> > 
> > I have absolutely no understanding of -where-, "the SuperBlock" [or how
> > that should be called], happens to be.
> 
> The MBR is not the XFS superblock.  sda5's XFS superblock is somewhere
> much further into the disk.
> 
> I don't think anyone here can tell you how to recreate the partitions,
> because nobody knows what their exact size was.
>  
> The XFS superblock signature is "XFSB" so you could go hexdumping the
> whole disk, look for eveny-spaced occurences of that pattern, and assume
> that you've found some superblocks, and work backwards from there.
> 
> All this is essentially data recovery, getting well beyond the scope of
> normal mailing-list help, though.
> 
> -Eric
> 
> > But, I feel that 512 bytes missing and no reason to believe a whole
> > Terabyte would be "ones and/ or zero's", now, I wonder, how to restore
> > this. I have not made backup of this harddrive, just an rsync, which is
> > a little outdated and a bit incomplete, because difference in size of
> > both drives.
> > 
> > I might be able to create a XFS-something [from /dev/sda, for example],
> > and write that with dd. 
> > 
> > But, before I would 'try this out', I would like to gain some
> > understanding, of what -should- be on the first 512 bytes of a
> > harddrive, besides what I have now, cfdisk is saying empty.
> > 
> > Hoping to receive a reply, Richard, the Netherlands
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: non mountable xfs with 2 primary and 2 logical

[Brian Foster]

On Wed, Jul 12, 2017 at 12:22:53PM +0000, Richard Waterbeek wrote:
> Hello Eric, linux-xfs list,
> 
> I have been thinking about getting myself options first.
> 
> I learned that;
> 
> The [Linux] operating system, doesn't recognize all "sda<number>"
> partition. But I have found a program "CG TestDisk". To avoid discuccins
> about that program, let me post a link to a screenshot, of what I have
> now.
> 
> First things first, the two NTFS partitions have been restored.
> 
> Then, I expect to find a 'sda5', and a 'sda6', [so that is an extended
> partition, containing two XFS partitions [524GB and 363GB]. 
> 
> The first screenshot is this program, again, to avoid discussing about
> that program, [CG TestDisk], my question is related to XFS. Because; I
> can tell, there seems to be a 'drive geometry', readable.
> 
> Here is the link to the screenshot;
> http://www.fotobakje.nl/map/div/linux/testdisk/testdisk-correcte-weergave.png [Notice the two green 'L']. However, it is reported as being 'HPFS/ NTFS'.
> 
> Now I wonder about the geometry, is it possible [and how], to calculate
> where mkfs.xfs, should have been written something [this is based on my
> expectations, I really have no real understanding of the XFS file
> system], so, where mkfs.xfs should have been written a [sda5 "mbr"],
> since I believe the SuperBlock or SuperBlocks are intact. Since you
> might have noticed there are five partitions in total [NTFS/ NTFS/ EXT4/
> XFS/ XFS], I wonder, is there a way, I make a call to the [most]
> knowledgable people here, to have a "xfs-<something", program or another
> way, to learn, -where-, "mkfs.xfs", should "find" [I actually mean where
> Linux expects an 'sda/ xfs block', to -mount- those file systems.
> 

It sounds like you've had a corrupted partition table, partially
restored it and are now trying to figure out where the last couple of
XFS partitions on the drive may reside. Note that partitions are just a
range of blocks to the filesystem. While sda5 might start on block N on
a physical drive, the fs simply sees it as block 0. IOW, the fs does not
know, care or have any information associated with the location of the
underlying disk partition.

Therefore, as Eric noted in the immediately previous reply, the only
recovery approach that I'm aware of is to manually search for XFS
superblocks in the range of sda that is still unaccounted for. You can
use hexdump to try and locate the blocks that start with the 'XFSB'
magic value, _hope_ they point to valid superblocks and try to recreate
your partitions from that information (the superblock should reside in
the first block of the partition). Of course you will want to
'xfs_repair -n' the associated partition to determine how broken the
filesystem is.

Brian

> This I ask [I know it is a bit complicated, trying to learn here],
> because; xfs_repair expects a mounted file system [ro]. And, with
> "guessing", and writing with mkfs.xfs which is easy for me to do, I can
> be almost sure, I will end up with an empty XFS file system. [Yes, the
> damaged drive, is still untouched by me], reading NTFS wasn't a pain.
> 
> I sincerely hope to get some waypointers, that will help me in my -own-
> search. Please do not tell me this isn't XFS related. It is XFS related,
> it might just be my person, willing and trying to be able, to understand
> XFS and where that [I expect 512 bytes sector, not a "mkfs.xfs
> recreation [that will make it bust for for sure], or if I am mistaken,
> please tell me about the options you are thinking of. I of course take
> full responsibillity for the steps I make [e.g. a real write to this
> hard drive], so no one to blame, if it fails somehow.
> 
> Richard.
> 
> 
> 
> 
> Eric Sandeen schreef op wo 28-06-2017 om 16:52 [-0500]:
> > On 6/28/17 4:43 PM, Richard Waterbeek wrote:
> > > Hi linux-xfs mailinglist,
> > > 
> > > I've recently subscribed to this list. I've seen many messages, but have
> > > little understading of the 'XFS' file system. I know about mkfs.xfs.
> > > I've benched my hardware. But, now my harddrive had a collision with the
> > > mbr somehow. [or something]
> > > 
> > > But, now I've 'hexdumped', the first 512 bytes, [because after a
> > > disaterous reboot, cfdisk is now saying; "/dev/sda empty".
> > 
> > If the xfs partition you lost was on extended partition sda5,
> > that's not at the front of the disk.  It sounds like something
> > overwrote your partition table. 
> > 
> > Honestly, recreating a partition table isn't an xfs issue.
> > 
> > > I'm aware of two primary and two logical partitions. I feel that I know
> > > the size of the first and second primary, but the xfs/ sda5 and, xfs
> > > sda6, are no longer appearing. I had to '#' the /etc/fstab, because it
> > > won't boot [long waiting].
> > > 
> > > Now I would like to restore the first 512 bytes which is the MBR.
> > > 
> > > I have absolutely no understanding of -where-, "the SuperBlock" [or how
> > > that should be called], happens to be.
> > 
> > The MBR is not the XFS superblock.  sda5's XFS superblock is somewhere
> > much further into the disk.
> > 
> > I don't think anyone here can tell you how to recreate the partitions,
> > because nobody knows what their exact size was.
> >  
> > The XFS superblock signature is "XFSB" so you could go hexdumping the
> > whole disk, look for eveny-spaced occurences of that pattern, and assume
> > that you've found some superblocks, and work backwards from there.
> > 
> > All this is essentially data recovery, getting well beyond the scope of
> > normal mailing-list help, though.
> > 
> > -Eric
> > 
> > > But, I feel that 512 bytes missing and no reason to believe a whole
> > > Terabyte would be "ones and/ or zero's", now, I wonder, how to restore
> > > this. I have not made backup of this harddrive, just an rsync, which is
> > > a little outdated and a bit incomplete, because difference in size of
> > > both drives.
> > > 
> > > I might be able to create a XFS-something [from /dev/sda, for example],
> > > and write that with dd. 
> > > 
> > > But, before I would 'try this out', I would like to gain some
> > > understanding, of what -should- be on the first 512 bytes of a
> > > harddrive, besides what I have now, cfdisk is saying empty.
> > > 
> > > Hoping to receive a reply, Richard, the Netherlands
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: non mountable xfs with 2 primary and 2 logical

[Richard Waterbeek]

Hello again, Brian, Eric, A C Cenci and xfs-list,

If you find this a lengthy post, the important part is three paragraphs and the two posted links narrow it down even more and might be sufficient to you.

For starters, A C Cenci, pointed me in to the right direction with an
url that made me notice that CG Testdisk, exists.

Eric gave a good response, stating that it wasn't XFS related. Which I
won't agree to.

And Brian, I've lost you a little [your second paragraph], but your answer to
my e-mail, is something for me to keep. For your first paragraph, I
wasn't able to view at a disk partition that way before. It helped me understanding what I had to do to be succesful.

What I have accomplished [besides hexdump 'hexdump -C /dev/sdb1' [where
sdb1 is a mountable and undamaged XFS], I couldn't really make heads or
tails out of, man pages, Red Hat webpages and cray docs XFS related
pages. But I did see the 'XFSB' string several times appearing from hexdump.

Now, where I find, I feel I got lucky, first, A C Cenci, pointed me
straight to a page with this CG TestDisk, where I -did- post my question
on it's forum, but it had to be moderated and somehow I didn't make it.
But comprehending CG TestDisk is kind of, "the write option means, it
will restore everything, or it will become even more unrepairable", which I can
understand now. Fiddling with CG TestDisk on a usb testing stick with a
similar setup [sda1/NTFS, sda2/NTFS, sda4/ extended and therefore sda5/
XFS and sda6/ XFS], made me comprehend how that program works.

It did recognize the sda5/ XFS and sda6/ XFS [with 'Quick Search'], as HPFS,
which would be type 7. Then I let it run on the whole 1TB to look for
more partitions, and what the manual said appeared to be true; deleted
partitions might also be found and I even saw a FAT12 partition, that
made me wonder, how that was possible. After almost three hours
of searching on the hard drive, it complained about the cylinders and heads, litteraly in the end,
not "being as expected".

But luckily I bought another 1TB SATA-600 2.5" hard drive from another
brand but with great price/ performance/ delivery option. And the drives
in question, stated on the drive label; CHS 16383/16/36. [Where I wonder how is it possible that CG Testdisk noticed invalidities] So my first
step before doing anything a simple dd
if=<source> of=<target> bs=8M, that after almost three hours of copying
with dd, everything was transfered. And on -that- disk, I did a write.
My steps where to leave CG TestDisk with what it found of the two NTFS,
and it did see the extended partition with the sda5 and sda6. Only, it
reported them as file system type 7. Now I have read somewhere, that a
linux file system usually is 83. And by working with mkfs.xfs on this
usb stick for testing purposes [a nullified one], I learned that XFS is
[also] seen/ reported by the linux operating system, as a file system
type 83. So I left two times type 7, and wrote two times type 83. Then,
changed /etc/fstab, the 'rw' part of those two XFS partitions to 'ro' and uncommented those again.
I am still verifying, if and where, data migh be corrupted [however
my sda6 wasn't totally full, which would explain this fuzzy FAT-12 find
I've had.] And, Brian, now I could mount those XFS partitions and
quickly went to my most important documents that appeared readable and without a
mangled beginning or end, which told me that the most easy way for me [I gave up on hexdump]
was to, doing my best to remember how I partitioned [primary or extended
and file system type] All the numbers seemed the same but I had a hard
time comprehending the "hexdump -C to XFSB" [besides the easy part, finding those strings] and [however if I was able to do so, I really would
have done a dry run with rebuilding since that is the only powerful thing against disaster]. 

What I have learned is that my laptop did something weird [lost /dev/sd<number> after a clean reboot]. I seriously rewrote my fstab, to not use UUID and such [a long time ago], but
for the bootable file system / I left it with it's UUID. I find that this can not or shouldn't be a problem, a 90 second waiting time on a linux distro, I find a problem.

As far I can guess, because I have no proof or traces, linux just reported
that /dev/sda5 and /dev/sda6 wheren't there any longer and also didn't
appear as "/dev/sdb5 and/ or /dev/sdb6" [which it also never did].

This is where you could start reading. I have no clue why cfdisk stated that it was
an empty /dev/sda, but I expect that CG TestDisk was able to find the
backup [which I have no knowledge for or understanding of]. So the magic that was done there, was beyond me. And besides
being a grateful person since you all have helped me with this, I
show my respect with a true, but lengthy post. And the big deal I find with XFS, after xfs_repair- n /dev/sd<number>, it said something about "moving to lost+found", so I've
checked those places and those where empty. Large zipped files did
decompress in full and without error. It is good to know [but maybe not
very informational [depending on your knowledge], that a recognized file
system type 7, might be a file system type 83, where what Brian said
about where hard disk volumes start to write, came to my mind. I'm pretty
sure that the way I believe how things work with hard drive file-systems, is not what really has happened. But for backing up my valuable
data [so no torrent movie or non personal media], I am now in the process of
looking at JFS and ZFS. If ZFS is kind of Btrfs, then I really will
have a look at JFS only. XFS performs really well with anything I find
[small files also], hdparm gave me higher results then that the brand of
that hard drive wrote themselves [160MB/s really isn't bad for a 2.5"
7200 rpm drive], and that is for me a real good reason to stick with XFS
[and do something more about backupping -properly-, and this time with a
hard drive that will be disconnected afterwards, and, to not forget, to
write valuable data to another file system, not necessarily the same
file system. And the JFS journal is something I will have a look at. But
I don't expect the high performance I'm having with XFS, so that I will
have to bench somehow.

Brian, Eric and A C Censi, thank you again, you have been most helpful.
I hope my response isn't viewed as spammy. I'm just a person that had a
computer boo boo, and find it logical and equally important, to write a thorough reply [which isn't only read, but also on the internet for other people]. Maybe I
found an easier way than restoring XFSB blocks with hexdump, because the
calculations I've made with it, never seemed right. And CG TestDisk, it
gives the restorable partitions in highlighted green on screen and with
doing a deeper search those two HPFS partitions didnt appear as XFS 6.2
+, but CG TestDisk, -did- print 'XFS 6.2+' on screen from there [if you find that my first link prooves otherwise, that is because that is the already repaired version]. What I make out of all
this, I was lucky to find a drive of another brand with the same
geometry, and somehow, it all turned out to be what Eric wrote, about
restoring the partition table. I only just would like to learn, how to
backup all those important information about the partitioning and where
the superblocks and backups are for example [or this partition table
itself, since that would be a good idea with a 1TB drive that isn't
easily backed up and will give me some down time too]. Now that I have
running my sda5 and sda6 again, I still have the option to redo my
findings on the "original" disk with the "original problem", that would save
me about three hours of dd'ing [and seems wiser then dd'ing things back]. [But somehow I believe those disk
geometry's where exactly the same, however dd also did tell something
here and there at the end of the drive geometry it saw. 

Thank you very much xfs-list, it might be simple what I wrote, but I
just believe it can be important to someone else. And CG TestDisk seems
XFS compatible and the CG TestDisk site wasn't really clear on this.
They didn't accept my post with my question but somehow also didn't gave
a response on the why, [or that my post still was in sent items, it was
like posting via a webpage and never receiving an e-mail with
confirmation], so I am a little xfs-list biased now. but don't expect me
to post a lengthy story again, ones misfortune just can help others. It
all matters on how the heck linux lost it's cookie. In my case might be Lenovo
ThinkPad bios related, and the media wasn't all positive about that [in
relation with linux and recognizing a volume, Windows is just working fine with them. And I forgot one thing which I believe 
is important; XFS seems to want a UPS. My laptop battery is a UPS.
The desktop I have besides it, doesn't have a UPS, I should look at if
there are file systems that make a difference in case of a unexpected 
outage. I just want to have something better then a USB based WD Elements.

To give some proof of my findings;

http://www.fotobakje.nl/map/div/linux/testdisk/testdisk-na-dd-met-type-83.png
Here you can see TestDisk, reading the partition table and telling that a XFS
can be a Linux, or a HPFS [fourth and fifth green line].

http://www.fotobakje.nl/map/div/linux/testdisk/testdisk-na-dd-met-type-83-toshiba.png
Here you can see cfdisk, reading the partition table and telling that a XFS
can be a Linux, type 83. And that was the way it was I believe. Now I
would like to backup those partition settings [and the superblocks if I am
not mistaken]. That would save me a lot of trouble next time and it for
sure will then be easier and less time consuming to get up and running.


Richard Waterbeek, the Netherlands



Brian Foster schreef op wo 12-07-2017 om 07:06 [-0400]:
> On Wed, Jul 12, 2017 at 12:22:53PM +0000, Richard Waterbeek wrote:
> > Hello Eric, linux-xfs list,
> > 
> > I have been thinking about getting myself options first.
> > 
> > I learned that;
> > 
> > The [Linux] operating system, doesn't recognize all "sda<number>"
> > partition. But I have found a program "CG TestDisk". To avoid discuccins
> > about that program, let me post a link to a screenshot, of what I have
> > now.
> > 
> > First things first, the two NTFS partitions have been restored.
> > 
> > Then, I expect to find a 'sda5', and a 'sda6', [so that is an extended
> > partition, containing two XFS partitions [524GB and 363GB]. 
> > 
> > The first screenshot is this program, again, to avoid discussing about
> > that program, [CG TestDisk], my question is related to XFS. Because; I
> > can tell, there seems to be a 'drive geometry', readable.
> > 
> > Here is the link to the screenshot;
> > http://www.fotobakje.nl/map/div/linux/testdisk/testdisk-correcte-weergave.png [Notice the two green 'L']. However, it is reported as being 'HPFS/ NTFS'.
> > 
> > Now I wonder about the geometry, is it possible [and how], to calculate
> > where mkfs.xfs, should have been written something [this is based on my
> > expectations, I really have no real understanding of the XFS file
> > system], so, where mkfs.xfs should have been written a [sda5 "mbr"],
> > since I believe the SuperBlock or SuperBlocks are intact. Since you
> > might have noticed there are five partitions in total [NTFS/ NTFS/ EXT4/
> > XFS/ XFS], I wonder, is there a way, I make a call to the [most]
> > knowledgable people here, to have a "xfs-<something", program or another
> > way, to learn, -where-, "mkfs.xfs", should "find" [I actually mean where
> > Linux expects an 'sda/ xfs block', to -mount- those file systems.
> > 
> 
> It sounds like you've had a corrupted partition table, partially
> restored it and are now trying to figure out where the last couple of
> XFS partitions on the drive may reside. Note that partitions are just a
> range of blocks to the filesystem. While sda5 might start on block N on
> a physical drive, the fs simply sees it as block 0. IOW, the fs does not
> know, care or have any information associated with the location of the
> underlying disk partition.
> 
> Therefore, as Eric noted in the immediately previous reply, the only
> recovery approach that I'm aware of is to manually search for XFS
> superblocks in the range of sda that is still unaccounted for. You can
> use hexdump to try and locate the blocks that start with the 'XFSB'
> magic value, _hope_ they point to valid superblocks and try to recreate
> your partitions from that information (the superblock should reside in
> the first block of the partition). Of course you will want to
> 'xfs_repair -n' the associated partition to determine how broken the
> filesystem is.
> 
> Brian
> 
> > This I ask [I know it is a bit complicated, trying to learn here],
> > because; xfs_repair expects a mounted file system [ro]. And, with
> > "guessing", and writing with mkfs.xfs which is easy for me to do, I can
> > be almost sure, I will end up with an empty XFS file system. [Yes, the
> > damaged drive, is still untouched by me], reading NTFS wasn't a pain.
> > 
> > I sincerely hope to get some waypointers, that will help me in my -own-
> > search. Please do not tell me this isn't XFS related. It is XFS related,
> > it might just be my person, willing and trying to be able, to understand
> > XFS and where that [I expect 512 bytes sector, not a "mkfs.xfs
> > recreation [that will make it bust for for sure], or if I am mistaken,
> > please tell me about the options you are thinking of. I of course take
> > full responsibillity for the steps I make [e.g. a real write to this
> > hard drive], so no one to blame, if it fails somehow.
> > 
> > Richard.
> > 
> > 
> > 
> > 
> > Eric Sandeen schreef op wo 28-06-2017 om 16:52 [-0500]:
> > > On 6/28/17 4:43 PM, Richard Waterbeek wrote:
> > > > Hi linux-xfs mailinglist,
> > > > 
> > > > I've recently subscribed to this list. I've seen many messages, but have
> > > > little understading of the 'XFS' file system. I know about mkfs.xfs.
> > > > I've benched my hardware. But, now my harddrive had a collision with the
> > > > mbr somehow. [or something]
> > > > 
> > > > But, now I've 'hexdumped', the first 512 bytes, [because after a
> > > > disaterous reboot, cfdisk is now saying; "/dev/sda empty".
> > > 
> > > If the xfs partition you lost was on extended partition sda5,
> > > that's not at the front of the disk.  It sounds like something
> > > overwrote your partition table. 
> > > 
> > > Honestly, recreating a partition table isn't an xfs issue.
> > > 
> > > > I'm aware of two primary and two logical partitions. I feel that I know
> > > > the size of the first and second primary, but the xfs/ sda5 and, xfs
> > > > sda6, are no longer appearing. I had to '#' the /etc/fstab, because it
> > > > won't boot [long waiting].
> > > > 
> > > > Now I would like to restore the first 512 bytes which is the MBR.
> > > > 
> > > > I have absolutely no understanding of -where-, "the SuperBlock" [or how
> > > > that should be called], happens to be.
> > > 
> > > The MBR is not the XFS superblock.  sda5's XFS superblock is somewhere
> > > much further into the disk.
> > > 
> > > I don't think anyone here can tell you how to recreate the partitions,
> > > because nobody knows what their exact size was.
> > >  
> > > The XFS superblock signature is "XFSB" so you could go hexdumping the
> > > whole disk, look for eveny-spaced occurences of that pattern, and assume
> > > that you've found some superblocks, and work backwards from there.
> > > 
> > > All this is essentially data recovery, getting well beyond the scope of
> > > normal mailing-list help, though.
> > > 
> > > -Eric
> > > 
> > > > But, I feel that 512 bytes missing and no reason to believe a whole
> > > > Terabyte would be "ones and/ or zero's", now, I wonder, how to restore
> > > > this. I have not made backup of this harddrive, just an rsync, which is
> > > > a little outdated and a bit incomplete, because difference in size of
> > > > both drives.
> > > > 
> > > > I might be able to create a XFS-something [from /dev/sda, for example],
> > > > and write that with dd. 
> > > > 
> > > > But, before I would 'try this out', I would like to gain some
> > > > understanding, of what -should- be on the first 512 bytes of a
> > > > harddrive, besides what I have now, cfdisk is saying empty.
> > > > 
> > > > Hoping to receive a reply, Richard, the Netherlands
> > > > 
> > > > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html