* Re: GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
From: Adam Goryachev @ 2016-07-26 4:18 UTC (permalink / raw)
To: David C. Rankin, mdraid
In-Reply-To: <5796B46B.6060905@suddenlinkmail.com>
On 26/07/16 10:52, David C. Rankin wrote:
> Neil, all,
>
> I really stepped in it this time. I have had a 3T raid1 array with 2 disks
> sdc/sdd that has worked fine since the new disks were partitioned and the arrays
> were created in August of last year. (simple 2-disk, raid1, ext4 - no
> encryption) Current kernel info on Archlinux is:
>
> # uname -a
> Linux valkyrie 4.6.4-1-ARCH #1 SMP PREEMPT Mon Jul 11 19:12:32 CEST 2016 x86_64
> GNU/Linux
>
> When the disks were partitioned originally and the arrays created, listing the
> partitioning showed no partition table problems. Today, a simple check of the
> partitioning by listing the partitions on sdc with 'gdisk -l /dev/sdc' brought
> up a curious error:
>
> # gdisk -l /dev/sdc
> GPT fdisk (gdisk) version 1.0.1
>
> Caution: invalid main GPT header, but valid backup; regenerating main header
> from backup!
>
> Caution! After loading partitions, the CRC doesn't check out!
> Warning! Main partition table CRC mismatch! Loaded backup partition table
> instead of main partition table!
>
> Warning! One or more CRCs don't match. You should repair the disk!
>
> Partition table scan:
> MBR: protective
> BSD: not present
> APM: not present
> GPT: damaged
>
> ****************************************************************************
> Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
> verification and recovery are STRONGLY recommended.
> ****************************************************************************
> Disk /dev/sdc: 5860533168 sectors, 2.7 TiB
> Logical sector size: 512 bytes
> Disk identifier (GUID): 3F835DD0-AA89-4F86-86BF-181F53FA1847
> Partition table holds up to 128 entries
> First usable sector is 34, last usable sector is 5860533134
> Partitions will be aligned on 2048-sector boundaries
> Total free space is 212958 sectors (104.0 MiB)
>
> Number Start (sector) End (sector) Size Code Name
> 1 8192 5860328334 2.7 TiB FD00 Linux RAID
>
> (sdd showed the same - it was probably fine all along and just the result of
> creating the arrays, but that would be par for my day...)
>
> Huh? All was functioning fine, even with the error -- until I tried to "fix" it.
> First, I searched for possible reasons on how the primary GPT table became
> corrupt. The reasons range from some non-GPT aware app tried to access the table
> (not anything I can think of here) or perhaps the Gigabyte "virtual bios" wrote
> a copy of the bios within the larger GPT table causing the issue, see:
> https://francisfisher.me.uk/problem/2014/warning-about-large-hard-discs-gpt-and-gigabyte-motherboards-such-as-ga-p35-ds4/)
> That sounds flaky, but I do have a Gigabyte GA-990FXA-UD3 Rev. 4 board.
>
> So after reading the posts, and reading the unix.stackexchange, superuser, etc.
> posts on the subject:
>
> http://www.rodsbooks.com/gdisk/repairing.html
> http://askubuntu.com/questions/465510/gpt-talbe-corrupt-after-raid1-setup
> https://ubuntuforums.org/showthread.php?t=1956173
> ...
>
> and various parted bugs about the opposite:
>
> https://lists.gnu.org/archive/html/bug-parted/2015-07/msg00003.html
>
> I came up with a plan to:
>
> - boot the Archlinux recovery cd 20160301 release CD
> - use gdisk /dev/sdd; r; v; c; w; to correct the table
> - --fail and --remove the disk from the array, and
> - readd the new disk, let it sync, then do the same for /dev/sdc
>
> (steps 1 & 2 went fine, but that's where I screwed up...).
>
> Now I'm left with an array (/dev/md4) in an inactive and probably
> un-salvageable. The data on the disks is backed up, so if there is no way to
> assemble and recover the data, I'm only out the time to recopy it. If I can save
> that, fine, but it isn't pressing. The current array state is:
>
> # cat /proc/mdstat
> Personalities : [raid1]
> md1 : active raid1 sdb6[1] sda6[0]
> 52396032 blocks super 1.2 [2/2] [UU]
>
> md0 : active raid1 sdb5[1] sda5[0]
> 511680 blocks super 1.2 [2/2] [UU]
>
> md3 : active raid1 sdb8[1] sda8[0]
> 2115584 blocks super 1.2 [2/2] [UU]
>
> md2 : active raid1 sdb7[1] sda7[0]
> 921030656 blocks super 1.2 [2/2] [UU]
> bitmap: 0/7 pages [0KB], 65536KB chunk
>
> md4 : inactive sdc[0](S)
> 2930135512 blocks super 1.2
>
> unused devices: <none>
>
> This is where I'm stuck. I've got the primary partition table issue on sdd
> fixed, I have not touched sdc (it is in the same state it was, when it was
> functioning with the complaint about the primary gpt partition table. I have
> tried activating the array with sdd1 "missing", but no joy. After correcting the
> partition table on sdd, it still contains the original partition, but I cannot
> get it (or sdc) to assemble in degraded or raid mode.
>
> I need help. Is there anything I can try to salvage the array? (at least one
> disk of the array?) If not, is there a way I can activate (or at least mount
> either sdc or sdd? -- it would be easier to dump the data rather than copying
> from multiple sources. It's ~258G, not huge, but not small)
>
> I know worst case is to wipe both disks (gdisk /dev/sd[cd] x; z; yes; yes) and
> start over, but with one disk of md4 that I haven't touched, it seems like I
> should be able to recover something?
>
> If the answer is just no, no, ..., then what is the best approach? zap with
> gdisk, wipe the superblocks and start over?
>
> If you need any other information that I haven't included, just let me know. I
> have the binary dumps of partition tables from sdc and sdd (from gdisk written
> to disk before any changes to sdd). Anyway, if there is anything else, just let
> me know and I'll post it.
>
> The server on which this array resides is running (this was just a data array,
> the boot, root, and home arrays are fine (they are mbr). I've just commented the
> mdadm.conf and fstab entries for the effected array.
>
> Last, but less important, any idea where this primary GPT corruption originated?
> (or was it fine all along and the error just a result of them being members of
> the array?) There are numerous posts over the last year related to:
>
> "invalid main GPT header, but valid backup"
>
> (and relating to raid1)
>
> but not many answers as to why. (if this was just a normal gdisk response from a
> raided disk, then there is a lot of 'bad' info out there. What is my best
> approach for attempting recovery from this self-created mess? Thanks.
>
>
It sounds/looks like you partitioned the two drives with GPT, and then
used the entire drive for the RAID, which probably overwrote at least
one of the GPT entries. Now gparted has overwritten part of the disk
where mdadm keeps it's data.
So, good news, assuming you really haven't touched sdc, then it should
still be fine. Try the following:
mdadm --manage --stop /dev/md4
Check it has stopped cat /proc/mdstat and md4 should not appear at all.
Now re-assemble with only the one working member:
mdadm --assemble --force /dev/md4 /dev/sdc
If you are lucky, you will then be able to mount /dev/md4 as needed.
If not, please provide:
Output of the above mdadm --assemble
Logs from syslog/dmesg in relation to the assembly attempt
mdadm --query /dev/sdc
mdadm --query /dev/sdc1
mdadm --query /dev/sdd
mdadm --query /dev/sdd1
mdadm --detail /dev/md4 (after the assemble above).
Being RAID1, it shouldn't be too hard to recover your data, just need to
get some more information about the current state.
Once you have the array started, your next step is to avoid the problem
in future. So send through the above details, and then additional advice
can be provided. Generally I've seen most people create the partition
and then use the partition for RAID, that way the partition is marked as
in-use by the array. The alternative is to wipe the beginning and end of
the drive (/dev/zero) and then re-add to the array. Once synced, you can
repeat with the other drive. The problem is if something (eg your BIOS)
decides to "initialise" the drive for you, then it will overwrite your
data/mdadm data.
Hope the above helps.
Regards,
Adam
--
Adam Goryachev Website Managers www.websitemanagers.com.au
^ permalink raw reply
* GPT corruption on Primary Header, backup OK, fixing primary nuked array -- help?
From: David C. Rankin @ 2016-07-26 0:52 UTC (permalink / raw)
To: mdraid
Neil, all,
I really stepped in it this time. I have had a 3T raid1 array with 2 disks
sdc/sdd that has worked fine since the new disks were partitioned and the arrays
were created in August of last year. (simple 2-disk, raid1, ext4 - no
encryption) Current kernel info on Archlinux is:
# uname -a
Linux valkyrie 4.6.4-1-ARCH #1 SMP PREEMPT Mon Jul 11 19:12:32 CEST 2016 x86_64
GNU/Linux
When the disks were partitioned originally and the arrays created, listing the
partitioning showed no partition table problems. Today, a simple check of the
partitioning by listing the partitions on sdc with 'gdisk -l /dev/sdc' brought
up a curious error:
# gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.1
Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!
Caution! After loading partitions, the CRC doesn't check out!
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!
Warning! One or more CRCs don't match. You should repair the disk!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Disk /dev/sdc: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 3F835DD0-AA89-4F86-86BF-181F53FA1847
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 212958 sectors (104.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 8192 5860328334 2.7 TiB FD00 Linux RAID
(sdd showed the same - it was probably fine all along and just the result of
creating the arrays, but that would be par for my day...)
Huh? All was functioning fine, even with the error -- until I tried to "fix" it.
First, I searched for possible reasons on how the primary GPT table became
corrupt. The reasons range from some non-GPT aware app tried to access the table
(not anything I can think of here) or perhaps the Gigabyte "virtual bios" wrote
a copy of the bios within the larger GPT table causing the issue, see:
https://francisfisher.me.uk/problem/2014/warning-about-large-hard-discs-gpt-and-gigabyte-motherboards-such-as-ga-p35-ds4/)
That sounds flaky, but I do have a Gigabyte GA-990FXA-UD3 Rev. 4 board.
So after reading the posts, and reading the unix.stackexchange, superuser, etc.
posts on the subject:
http://www.rodsbooks.com/gdisk/repairing.html
http://askubuntu.com/questions/465510/gpt-talbe-corrupt-after-raid1-setup
https://ubuntuforums.org/showthread.php?t=1956173
...
and various parted bugs about the opposite:
https://lists.gnu.org/archive/html/bug-parted/2015-07/msg00003.html
I came up with a plan to:
- boot the Archlinux recovery cd 20160301 release CD
- use gdisk /dev/sdd; r; v; c; w; to correct the table
- --fail and --remove the disk from the array, and
- readd the new disk, let it sync, then do the same for /dev/sdc
(steps 1 & 2 went fine, but that's where I screwed up...).
Now I'm left with an array (/dev/md4) in an inactive and probably
un-salvageable. The data on the disks is backed up, so if there is no way to
assemble and recover the data, I'm only out the time to recopy it. If I can save
that, fine, but it isn't pressing. The current array state is:
# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb6[1] sda6[0]
52396032 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sdb5[1] sda5[0]
511680 blocks super 1.2 [2/2] [UU]
md3 : active raid1 sdb8[1] sda8[0]
2115584 blocks super 1.2 [2/2] [UU]
md2 : active raid1 sdb7[1] sda7[0]
921030656 blocks super 1.2 [2/2] [UU]
bitmap: 0/7 pages [0KB], 65536KB chunk
md4 : inactive sdc[0](S)
2930135512 blocks super 1.2
unused devices: <none>
This is where I'm stuck. I've got the primary partition table issue on sdd
fixed, I have not touched sdc (it is in the same state it was, when it was
functioning with the complaint about the primary gpt partition table. I have
tried activating the array with sdd1 "missing", but no joy. After correcting the
partition table on sdd, it still contains the original partition, but I cannot
get it (or sdc) to assemble in degraded or raid mode.
I need help. Is there anything I can try to salvage the array? (at least one
disk of the array?) If not, is there a way I can activate (or at least mount
either sdc or sdd? -- it would be easier to dump the data rather than copying
from multiple sources. It's ~258G, not huge, but not small)
I know worst case is to wipe both disks (gdisk /dev/sd[cd] x; z; yes; yes) and
start over, but with one disk of md4 that I haven't touched, it seems like I
should be able to recover something?
If the answer is just no, no, ..., then what is the best approach? zap with
gdisk, wipe the superblocks and start over?
If you need any other information that I haven't included, just let me know. I
have the binary dumps of partition tables from sdc and sdd (from gdisk written
to disk before any changes to sdd). Anyway, if there is anything else, just let
me know and I'll post it.
The server on which this array resides is running (this was just a data array,
the boot, root, and home arrays are fine (they are mbr). I've just commented the
mdadm.conf and fstab entries for the effected array.
Last, but less important, any idea where this primary GPT corruption originated?
(or was it fine all along and the error just a result of them being members of
the array?) There are numerous posts over the last year related to:
"invalid main GPT header, but valid backup"
(and relating to raid1)
but not many answers as to why. (if this was just a normal gdisk response from a
raided disk, then there is a lot of 'bad' info out there. What is my best
approach for attempting recovery from this self-created mess? Thanks.
--
David C. Rankin, J.D.,P.E.
^ permalink raw reply
* Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
From: Adam Goryachev @ 2016-07-25 23:08 UTC (permalink / raw)
To: bobzer, linux-raid
In-Reply-To: <CADzS=aqYQEoqxHbp7keeuYqN2dLur1O=RfctfuFsraggxiWTKg@mail.gmail.com>
On 26/07/16 07:14, bobzer wrote:
> Hi,
>
> I'm looking for advice to not mess up my migration. because
> unfortunately i miss drive
> I wanna migrate all my data from a raid 5 of 4x2TB (actually 3 because
> i'm degraded right now) to a raid 6 of 4x4TB
> so exactly i got :
> - raid 5, should be 4 disk of 2T but got problem and so right now it's
> just 2x2T and a 2Tb disk image in a 4T disk (the raid crashed and is
> not start right now but is clean)
> - 2 disk of 4TB
> - the raid 5 use lvm2 on top of mdadm
>
> I want a raid 6 so i thought i could create a raid 6 degraded with the
> 2x4TB and after copy the data to this new raid and after add the third
> 4TB and finally add the 2 2TB as a raid 0 to get a 4TB
> I know it's an ideal solution to get 3x4TB + 2x2TB to do my raid but
> it give me time to invest.
>
> So my question is :
> - is it a really bad idea ?
> - do you have a better idea? solution ?
> - maybe i can migrate instead of copy a raid to another ?
>
> thank you very much
> Math
My head hurts, I don't understand what you currently have, but I think
you have:
RAID5 with three members, sda1(2TB), sdb1(2TB) and an 2TB image stored
on sdc1(4TB)
Two spare 4TB drives sdd1 and sde1.
I would do a replace from the image on sdc1 to sde1
Do a replace from sda1 to sdc1
Do a replace from sdb1 to sdd1
Create a RAID0 array on sda1 + sdb1 (linear or stripe, guess it doesn't
matter much either way, though if performance matters, then think about
this as it will throw out the expected performance of your array).
Do a add of the RAID0 to the RAID5 (it will add as a spare)
Do a grow of the RAID5 to RAID6
Do a grow --size=max to increase capacity to the smallest drive (don't
do the grow earlier, the RAID0 might be slightly smaller).
The above means at no point is your RAID5 degraded, and you end up with
RAID6.
It will probably take some time to do all that, I'm not sure if the 2nd
and 3rd steps can be done in parallel or not...
PS, you should take a copy of all your RAID information and drive member
details (lsdrv script) before commencing so that if something goes
wrong, you have the best chance of recovery.
!!!Also, definitely ensure you have SCT/ERC configured properly on both
the old and new drives!!!
Regards,
Adam
--
Adam Goryachev Website Managers www.websitemanagers.com.au
^ permalink raw reply
* Re: migration of raid 5 to raid 6 and disk of 2TB to 4TB
From: Wols Lists @ 2016-07-25 22:48 UTC (permalink / raw)
To: bobzer, linux-raid
In-Reply-To: <CADzS=aqYQEoqxHbp7keeuYqN2dLur1O=RfctfuFsraggxiWTKg@mail.gmail.com>
On 25/07/16 22:14, bobzer wrote:
> Hi,
>
> I'm looking for advice to not mess up my migration. because
> unfortunately i miss drive
> I wanna migrate all my data from a raid 5 of 4x2TB (actually 3 because
> i'm degraded right now) to a raid 6 of 4x4TB
> so exactly i got :
> - raid 5, should be 4 disk of 2T but got problem and so right now it's
> just 2x2T and a 2Tb disk image in a 4T disk (the raid crashed and is
> not start right now but is clean)
> - 2 disk of 4TB
> - the raid 5 use lvm2 on top of mdadm
>
> I want a raid 6 so i thought i could create a raid 6 degraded with the
> 2x4TB and after copy the data to this new raid and after add the third
> 4TB and finally add the 2 2TB as a raid 0 to get a 4TB
> I know it's an ideal solution to get 3x4TB + 2x2TB to do my raid but
> it give me time to invest.
>
> So my question is :
> - is it a really bad idea ?
> - do you have a better idea? solution ?
> - maybe i can migrate instead of copy a raid to another ?
Yup. You should be able to migrate.
Add in one of the 4TB drives as 4TB. It'll only use 2TB because it
matches the other drives, but it'll get your raid 5 back fully redundant.
Now replace the two 2TB drives with the 4TB drives. Use the --replace
option to mdadm - it's fairly new.
Then I think you'll have to fail the 2TB image in order to add the last
4TB drive in - maybe you won't - others might be able to help here ...
or you might be able to just remove the 2TB image and convert it to a
full raid 5 on 3 x 4TB disks - that's the best option if you can because
at no point are you surrendering a working raid and risking a failure.
(The thing to remember, is that raid will take the smallest drive, and
use that amount of space on all the drives. If you replace all the 2TBs
with 4TBs, suddenly the raid can use the full 4TB.)
Now you're using half your raid-space for your array, you should be able
to convert to raid 6, then expand the array to use the new space. I'm
not sure exactly how all this works, but having replaced all 2TB drives
with 4TB drives, I'm sure mdadm can claim the expanded space.
JUST MAKE SURE YOUR NEW DRIVES ARE ENTERPRISE RAID DRIVES! What are
they? WD Reds? Seagate NAS? If they don't support SCT/ERC or whatever
it's called, then your array will be a time bomb!
> thank you very much
> Math
Cheers,
Wol
^ permalink raw reply
* migration of raid 5 to raid 6 and disk of 2TB to 4TB
From: bobzer @ 2016-07-25 21:14 UTC (permalink / raw)
To: linux-raid
Hi,
I'm looking for advice to not mess up my migration. because
unfortunately i miss drive
I wanna migrate all my data from a raid 5 of 4x2TB (actually 3 because
i'm degraded right now) to a raid 6 of 4x4TB
so exactly i got :
- raid 5, should be 4 disk of 2T but got problem and so right now it's
just 2x2T and a 2Tb disk image in a 4T disk (the raid crashed and is
not start right now but is clean)
- 2 disk of 4TB
- the raid 5 use lvm2 on top of mdadm
I want a raid 6 so i thought i could create a raid 6 degraded with the
2x4TB and after copy the data to this new raid and after add the third
4TB and finally add the 2 2TB as a raid 0 to get a 4TB
I know it's an ideal solution to get 3x4TB + 2x2TB to do my raid but
it give me time to invest.
So my question is :
- is it a really bad idea ?
- do you have a better idea? solution ?
- maybe i can migrate instead of copy a raid to another ?
thank you very much
Math
^ permalink raw reply
* Re: [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion
From: Jeff Moyer @ 2016-07-25 20:39 UTC (permalink / raw)
To: Eric Wheeler
Cc: Lars Ellenberg, Mike Snitzer, NeilBrown, Jens Axboe, linux-block,
Martin K. Petersen, Peter Zijlstra, Jiri Kosina, Ming Lei,
Kirill A. Shutemov, linux-kernel, linux-raid, Takashi Iwai,
linux-bcache, Zheng Liu, Kent Overstreet, Keith Busch, dm-devel,
Shaohua Li, Ingo Molnar, Alasdair Kergon, Roland Kammerer,
Mikulas Patocka
In-Reply-To: <alpine.LRH.2.11.1607211547450.21453@mail.ewheeler.net>
Eric Wheeler <bcache@lists.ewheeler.net> writes:
> [+cc Mikulas Patocka, Jeff Moyer; Do either of you have any input on Lars'
> commentary related to patchwork #'s 9204125 and 7398411 and BZ#119841? ]
Sorry, I don't have any time to look at this right now.
Cheers,
Jeff
>
> On Tue, 19 Jul 2016, Lars Ellenberg wrote:
>
>> On Tue, Jul 12, 2016 at 10:32:33PM -0400, Mike Snitzer wrote:
>> > On Tue, Jul 12 2016 at 10:18pm -0400,
>> > Eric Wheeler <bcache@lists.ewheeler.net> wrote:
>> >
>> > > On Tue, 12 Jul 2016, NeilBrown wrote:
>> > >
>> > > > On Tue, Jul 12 2016, Lars Ellenberg wrote:
>> > > > ....
>> > > > >
>> > > > > Instead, I suggest to distinguish between recursive calls to
>> > > > > generic_make_request(), and pushing back the remainder part in
>> > > > > blk_queue_split(), by pointing current->bio_lists to a
>> > > > > struct recursion_to_iteration_bio_lists {
>> > > > > struct bio_list recursion;
>> > > > > struct bio_list queue;
>> > > > > }
>> > > > >
>> > > > > By providing each q->make_request_fn() with an empty "recursion"
>> > > > > bio_list, then merging any recursively submitted bios to the
>> > > > > head of the "queue" list, we can make the recursion-to-iteration
>> > > > > logic in generic_make_request() process deepest level bios first,
>> > > > > and "sibling" bios of the same level in "natural" order.
>> > > > >
>> > > > > Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
>> > > > > Signed-off-by: Roland Kammerer <roland.kammerer@linbit.com>
>> > > >
>> > > > Reviewed-by: NeilBrown <neilb@suse.com>
>> > > >
>> > > > Thanks again for doing this - I think this is a very significant
>> > > > improvement and could allow other simplifications.
>> > >
>> > > Thank you Lars for all of this work!
>> > >
>> > > It seems like there have been many 4.3+ blockdev stacking issues and this
>> > > will certainly address some of those (maybe all of them?). (I think we
>> > > hit this while trying drbd in 4.4 so we dropped back to 4.1 without
>> > > issue.) It would be great to hear 4.4.y stable pick this up if
>> > > compatible.
>> > >
>> > >
>> > > Do you believe that this patch would solve any of the proposals by others
>> > > since 4.3 related to bio splitting/large bios? I've been collecting a
>> > > list, none of which appear have landed yet as of 4.7-rc7 (but correct me
>> > > if I'm wrong):
>> > >
>> > > A. [PATCH v2] block: make sure big bio is splitted into at most 256 bvecs
>> > > by Ming Lei: https://patchwork.kernel.org/patch/9169483/
>>
>> That's an independend issue.
>>
>> > > B. block: don't make BLK_DEF_MAX_SECTORS too big
>> > > by Shaohua Li: http://www.spinics.net/lists/linux-bcache/msg03525.html
>>
>> Yet an other independend issue.
>>
>> > > C. [1/3] block: flush queued bios when process blocks to avoid deadlock
>> > > by Mikulas Patocka: https://patchwork.kernel.org/patch/9204125/
>> > > (was https://patchwork.kernel.org/patch/7398411/)
>>
>> As it stands now,
>> this is yet an other issue, but related.
>>
>> From the link above:
>>
>> | ** Here is the dm-snapshot deadlock that was observed:
>> |
>> | 1) Process A sends one-page read bio to the dm-snapshot target. The bio
>> | spans snapshot chunk boundary and so it is split to two bios by device
>> | mapper.
>> |
>> | 2) Device mapper creates the first sub-bio and sends it to the snapshot
>> | driver.
>> |
>> | 3) The function snapshot_map calls track_chunk (that allocates a
>> | structure
>> | dm_snap_tracked_chunk and adds it to tracked_chunk_hash) and then remaps
>> | the bio to the underlying device and exits with DM_MAPIO_REMAPPED.
>> |
>> | 4) The remapped bio is submitted with generic_make_request, but it isn't
>> | issued - it is added to current->bio_list instead.
>> |
>> | 5) Meanwhile, process B (dm's kcopyd) executes pending_complete for the
>> | chunk affected be the first remapped bio, it takes down_write(&s->lock)
>> | and then loops in __check_for_conflicting_io, waiting for
>> | dm_snap_tracked_chunk created in step 3) to be released.
>> |
>> | 6) Process A continues, it creates a second sub-bio for the rest of the
>> | original bio.
>>
>> Aha.
>> Here is the relation.
>> If "A" had only ever processed "just the chunk it can handle now",
>> and "pushed back" the rest of the incoming bio,
>> it could rely on all deeper level bios to have been submitted already.
>>
>> But this does not look like it easily fits into the current DM model.
>>
>> | 7) snapshot_map is called for this new bio, it waits on
>> | down_write(&s->lock) that is held by Process B (in step 5).
>>
>> There is an other suggestion:
>> Use down_trylock (or down_timeout),
>> and if it fails, push back the currently to-be-processed bio.
>> We can introduce a new bio helper for that.
>> Kind of what blk_queue_split() does with my patch applied.
>>
>> Or even better, ignore the down_trylock suggestion,
>> simply not iterate over all pieces first,
>> but process one piece, and return back the the
>> iteration in generic_make_request.
>>
>> A bit of conflict here may be that DM has all its own
>> split and clone and queue magic, and wants to process
>> "all of the bio" before returning back to generic_make_request().
>>
>> To change that, __split_and_process_bio() and all its helpers
>> would need to learn to "push back" (pieces of) the bio they are
>> currently working on, and not push back via "DM_ENDIO_REQUEUE",
>> but by bio_list_add_head(¤t->bio_lists->queue, piece_to_be_done_later).
>>
>> Then, after they processed each piece,
>> *return* all the way up to the top-level generic_make_request(),
>> where the recursion-to-iteration logic would then
>> make sure that all deeper level bios, submitted via
>> recursive calls to generic_make_request() will be processed, before the
>> next, pushed back, piece of the "original incoming" bio.
>>
>> And *not* do their own iteration over all pieces first.
>>
>> Probably not as easy as dropping the while loop,
>> using bio_advance, and pushing that "advanced" bio back to
>> current->...queue?
>>
>> static void __split_and_process_bio(struct mapped_device *md,
>> struct dm_table *map, struct bio *bio)
>> ...
>> ci.bio = bio;
>> ci.sector_count = bio_sectors(bio);
>> while (ci.sector_count && !error)
>> error = __split_and_process_non_flush(&ci);
>> ...
>> error = __split_and_process_non_flush(&ci);
>> if (ci.sector_count)
>> bio_advance()
>> bio_list_add_head(¤t->bio_lists->queue, )
>> ...
>>
>> Something like that, maybe?
>> Just a thought.
>>
>> > > D. dm-crypt: Fix error with too large bios
>> > > by Mikulas Patocka: https://patchwork.kernel.org/patch/9138595/
>> > >
>> > > The A,B,D are known to fix large bio issues when stacking dm+bcache
>> > > (though the B,D are trivial and probably necessary even with your patch).
>> > >
>> > > Patch C was mentioned earlier in this thread by Mike Snitzer and you
>> > > commented briefly that his patch might solve the issue; given that, and in
>> > > the interest of minimizing duplicate effort, which of the following best
>> > > describes the situation?
>> > >
>> > > 1. Your patch could supersede Mikulas's patch; they address the same
>> > > issue.
>> > >
>> > > 2. Mikulas's patch addresses different issues such and both patches
>> > > should be applied.
>> > >
>> > > 3. There is overlap between both your patch and Mikulas's such that both
>> > > #1,#2 are true and effort to solve this has been duplicated.
>> > >
>> > >
>> > > If #3, then what might be done to resolve the overlap?
>> >
>> > Mikulas confirmed to me that he believes Lars' v2 patch will fix the
>> > dm-snapshot problem, which is being tracked with this BZ:
>> > https://bugzilla.kernel.org/show_bug.cgi?id=119841
>> >
>> > We'll see how testing goes (currently underway).
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply
* Re: Cannot start array on disk
From: Bhatia Amit @ 2016-07-23 22:47 UTC (permalink / raw)
To: Phil Turmel, linux-raid@vger.kernel.org
In-Reply-To: <bc8e09fe-c489-e85d-bb8a-c3c9ff0b9588@turmel.org>
> The old and new data are completely different filesystems, I believe.
> And I suspect the folder data for the latter half of the disk is in the
> (missing) first half of the disk. Certainly the root folder. If
> r-linux can recover file contents, that's better than I've got. I doubt
> you have any folder data for the new < half disk.
>
> > In an earlier email, you had suggested possibly running fsck on sdc4
> > partition. Is that something I should be considering?
>
> No, I don't believe it can handle anything like this. You might want to
> share this thread with the ext4 list.
Hi Phil
I think I understand the issue you are describing here. Also, I will share this thread with the ext4 list to get their suggestion.
Thanks for the all help.
Amit
^ permalink raw reply
* Re: Cannot start array on disk
From: Phil Turmel @ 2016-07-23 22:30 UTC (permalink / raw)
To: Bhatia Amit, linux-raid@vger.kernel.org
In-Reply-To: <578225037.3489302.1469312496573.JavaMail.yahoo@mail.yahoo.com>
On 07/23/2016 06:21 PM, Bhatia Amit wrote:
> Just to clarify, I am ok getting *all* data out of disk, whether old
> or new. My key issue is that while r-linux showed me files that it
> could recover, it did not show me any folder information. So, if
> getting folder information out requires getting all data out, I am
> fine with it. What is the way to get this information out for all
> data? Maybe I am missing something, but is getting data (old/new) out
> from disk too difficult ?
The old and new data are completely different filesystems, I believe.
And I suspect the folder data for the latter half of the disk is in the
(missing) first half of the disk. Certainly the root folder. If
r-linux can recover file contents, that's better than I've got. I doubt
you have any folder data for the new < half disk.
> In an earlier email, you had suggested possibly running fsck on sdc4
> partition. Is that something I should be considering?
No, I don't believe it can handle anything like this. You might want to
share this thread with the ext4 list.
Phil
^ permalink raw reply
* Re: Cannot start array on disk
From: Bhatia Amit @ 2016-07-23 22:21 UTC (permalink / raw)
To: Phil Turmel, linux-raid@vger.kernel.org
In-Reply-To: <b151a240-c3a4-3b59-0ba5-b6ac5776a16d@turmel.org>
> This one has a write timestamp of Mon Apr 04 16:02:53 EDT 2016.
>
> So more than half of this volume is old data, possibly part of an empty
> default setup. The latter part of the disk, but less than half, is more
> recent data.
>
> I don't have anything more to suggest. I don't know of any way to get
> just the good data, however much, at the end of the volume without the
> first half of the disk.
Hi Phil
Just to clarify, I am ok getting *all* data out of disk, whether old or new. My key issue is that while r-linux showed me files that it could recover, it did not show me any folder information. So, if getting folder information out requires getting all data out, I am fine with it. What is the way to get this information out for all data? Maybe I am missing something, but is getting data (old/new) out from disk too difficult ?
In an earlier email, you had suggested possibly running fsck on sdc4 partition. Is that something I should be considering?
Thanks,
Amit
^ permalink raw reply
* Re: Cannot start array on disk
From: Phil Turmel @ 2016-07-23 20:50 UTC (permalink / raw)
To: Bhatia Amit, linux-raid@vger.kernel.org
In-Reply-To: <1152956900.3399623.1469246417006.JavaMail.yahoo@mail.yahoo.com>
Hi Amit,
You're not going like this news:
On 07/23/2016 12:00 AM, Bhatia Amit wrote:
> Following is the output from hexdump command you suggested above. Additionally, the r-linux tool that I had used to scan the disk for files, had claimed to find superblocks at multiple locations on disk. So, after the hexdump output, I have also dumped some information from hex output of the claimed superblock region, from three locations (first, middle and last superblock) on disk. Also, each superblock is claimed to occupy 2 sectors, but I have only pasted the first sector here, because the second sector is all zeros. The first two superblocks look to be exactly the same, but the last one seems a little different.
> fff80030 47 9d ba 50 03 00 1b 00 53 ef 00 00 01 00 00 00 |G..P....S.......|
> $ cat sblock.txt
>
> Name: Ext2/Ext3/Ext4 SuperBlock
> Offset (in sectors): 8387584
> Size (in sectors): 2
>
>
> Sector 8387584 (Parent: WDC WD30EZRX-00D8PB0 80.00A80 Record: 17419264)
>
> FFF80000: 00 46 B7 02 5F 8C B9 02 - 00 00 00 00 62 25 B6 02 .F.._.......b%..
> FFF80010: 1A 3B B7 02 00 00 00 00 - 06 00 00 00 06 00 00 00 .;..............
> FFF80020: F8 FF 00 00 F8 FF 00 00 - 00 FF 00 00 43 3E B3 4F ............C>.O
> FFF80030: 47 9D BA 50 03 00 1B 00 - 53 EF 00 00 01 00 00 00 G..P....S.......
> FFF80040: 3B B5 02 00 00 4E ED 00 - 00 00 00 00 01 00 00 00 ;....N..........
> FFF80050: 00 00 00 00 0B 00 00 00 - 00 01 01 00 3C 00 00 00 ............<...
> FFF80060: 42 02 00 00 7B 00 00 00 - B6 7F 9F FD 12 BF 4D 57 B...{.........MW
> FFF80070: A8 34 DD 09 E9 E8 BA C0 - 00 00 00 00 00 00 00 00 .4..............
> FFF80080: 00 00 00 00 00 00 00 00 - 2F 43 61 63 68 65 56 6F ......../CacheVo
> FFF80090: 6C 75 6D 65 00 C8 24 9E - 20 22 82 24 22 C8 1B 60 lume..$. ".$"..`
> FFF800A0: 60 FF FF FF 9C CA D0 E4 - 5C C8 13 41 80 C0 10 E6 `.......\..A....
> FFF800B0: 68 C8 08 21 60 CA D0 E4 - 5C 00 00 00 00 CD AC 46 h..!`...\......F
> FFF800C0: 80 C8 1C 5A 60 C8 24 9E - 00 00 00 00 00 00 20 00 ...Z`.$....... .
> FFF800D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> FFF800E0: 08 00 00 00 00 00 00 00 - 00 00 00 00 FC ED 10 2F .............../
> FFF800F0: 38 44 66 85 D0 AC 7C A3 - FF F3 B0 AF 01 01 00 00 8Df...|.........
> FFF80100: 00 00 00 00 00 00 00 00 - 3B B5 02 00 0A F3 02 00 ........;.......
> FFF80110: 04 00 00 00 00 00 00 00 - 00 00 00 00 FF 7F 00 00 ................
> FFF80120: 78 EA B0 02 FF 7F 00 00 - 01 00 00 00 77 6A B1 02 x...........wj..
> FFF80130: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> FFF80140: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 80 ................
> FFF80150: 00 00 00 00 00 00 00 00 - 00 00 00 00 1C 00 1C 00 ................
> FFF80160: 02 00 00 00 FF 78 00 00 - 00 00 00 00 00 00 00 00 .....x..........
> FFF80170: 00 00 00 00 04 00 00 00 - 94 F3 87 01 00 00 00 00 ................
> FFF80180: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> FFF80190: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> FFF801A0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> FFF801B0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> FFF801C0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> FFF801D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> FFF801E0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> FFF801F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
>
>
>
> Name: Ext2/Ext3/Ext4 SuperBlock
> Offset (in sectors): 2038182912
> Size (in sectors): 2
>
>
> Sector 2038182912 (Parent: WDC WD30EZRX-00D8PB0 80.00A80 Record: 2047214592)
>
>
> F2F8680000: 00 46 B7 02 5F 8C B9 02 - 00 00 00 00 62 25 B6 02 .F.._.......b%..
> F2F8680010: 1A 3B B7 02 00 00 00 00 - 06 00 00 00 06 00 00 00 .;..............
> F2F8680020: F8 FF 00 00 F8 FF 00 00 - 00 FF 00 00 43 3E B3 4F ............C>.O
> F2F8680030: 47 9D BA 50 03 00 1B 00 - 53 EF 00 00 01 00 00 00 G..P....S.......
> F2F8680040: 3B B5 02 00 00 4E ED 00 - 00 00 00 00 01 00 00 00 ;....N..........
> F2F8680050: 00 00 00 00 0B 00 00 00 - 00 01 F3 00 3C 00 00 00 ............<...
> F2F8680060: 42 02 00 00 7B 00 00 00 - B6 7F 9F FD 12 BF 4D 57 B...{.........MW
> F2F8680070: A8 34 DD 09 E9 E8 BA C0 - 00 00 00 00 00 00 00 00 .4..............
> F2F8680080: 00 00 00 00 00 00 00 00 - 2F 43 61 63 68 65 56 6F ......../CacheVo
> F2F8680090: 6C 75 6D 65 00 C8 24 9E - 20 22 82 24 22 C8 1B 60 lume..$. ".$"..`
> F2F86800A0: 60 FF FF FF 9C CA D0 E4 - 5C C8 13 41 80 C0 10 E6 `.......\..A....
> F2F86800B0: 68 C8 08 21 60 CA D0 E4 - 5C 00 00 00 00 CD AC 46 h..!`...\......F
> F2F86800C0: 80 C8 1C 5A 60 C8 24 9E - 00 00 00 00 00 00 20 00 ...Z`.$....... .
> F2F86800D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> F2F86800E0: 08 00 00 00 00 00 00 00 - 00 00 00 00 FC ED 10 2F .............../
> F2F86800F0: 38 44 66 85 D0 AC 7C A3 - FF F3 B0 AF 01 01 00 00 8Df...|.........
> F2F8680100: 00 00 00 00 00 00 00 00 - 3B B5 02 00 0A F3 02 00 ........;.......
> F2F8680110: 04 00 00 00 00 00 00 00 - 00 00 00 00 FF 7F 00 00 ................
> F2F8680120: 78 EA B0 02 FF 7F 00 00 - 01 00 00 00 77 6A B1 02 x...........wj..
> F2F8680130: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> F2F8680140: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 80 ................
> F2F8680150: 00 00 00 00 00 00 00 00 - 00 00 00 00 1C 00 1C 00 ................
> F2F8680160: 02 00 00 00 FF 78 00 00 - 00 00 00 00 00 00 00 00 .....x..........
> F2F8680170: 00 00 00 00 04 00 00 00 - 94 F3 87 01 00 00 00 00 ................
> F2F8680180: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> F2F8680190: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> F2F86801A0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> F2F86801B0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> F2F86801C0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> F2F86801D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> F2F86801E0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> F2F86801F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
These two superblocks above have a write timestamp of Sat Dec 01
19:13:59 EST 2012. Little endian "47 9D BA 50". See
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block
> Name: Ext2/Ext3/Ext4 SuperBlock
> Offset (in sectors): 5781334786
> Size (in sectors): 2
>
>
>
> Sector 5781334786 (Parent: WDC WD30EZRX-00D8PB0 80.00A80 Record: 5790366466)
>
>
> 2B130560400: 00 46 B7 02 5F 8C B9 02 - 00 00 00 00 25 7F 09 02 .F.._.......%...
> 2B130560410: DC F8 99 02 00 00 00 00 - 06 00 00 00 06 00 00 00 ................
> 2B130560420: F8 FF 00 00 F8 FF 00 00 - 00 FF 00 00 6D C8 02 57 ............m..W
> 2B130560430: 6D C8 02 57 2E 00 1B 00 - 53 EF 01 00 01 00 00 00 m..W....S.......
> 2B130560440: 3B B5 02 00 00 4E ED 00 - 00 00 00 00 01 00 00 00 ;....N..........
> 2B130560450: 00 00 00 00 0B 00 00 00 - 00 01 00 00 3C 00 00 00 ............<...
> 2B130560460: 46 02 00 00 7B 00 00 00 - B6 7F 9F FD 12 BF 4D 57 F...{.........MW
> 2B130560470: A8 34 DD 09 E9 E8 BA C0 - 00 00 00 00 00 00 00 00 .4..............
> 2B130560480: 00 00 00 00 00 00 00 00 - 2F 43 61 63 68 65 56 6F ......../CacheVo
> 2B130560490: 6C 75 6D 65 00 C7 4B BE - 20 24 82 24 82 C8 1B A0 lume..K. $.$....
> 2B1305604A0: 60 FF FF FF 9C C0 F1 11 - DC C8 13 2A A0 C0 10 E6 `..........*....
> 2B1305604B0: 68 C8 08 21 60 C0 F1 11 - DC 00 00 00 00 CF 3D 2A h..!`.........=*
> 2B1305604C0: E0 C2 94 C1 60 C7 4B BE - 00 00 00 00 00 00 20 00 ....`.K....... .
> 2B1305604D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 2B1305604E0: 08 00 00 00 00 00 00 00 - 00 00 00 00 FC ED 10 2F .............../
> 2B1305604F0: 38 44 66 85 D0 AC 7C A3 - FF F3 B0 AF 01 01 00 00 8Df...|.........
> 2B130560500: 00 00 00 00 00 00 00 00 - 3B B5 02 00 0A F3 02 00 ........;.......
> 2B130560510: 04 00 00 00 00 00 00 00 - 00 00 00 00 FF 7F 00 00 ................
> 2B130560520: 78 EA B0 02 FF 7F 00 00 - 01 00 00 00 77 6A B1 02 x...........wj..
> 2B130560530: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 2B130560540: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 80 ................
> 2B130560550: 00 00 00 00 00 00 00 00 - 00 00 00 00 1C 00 1C 00 ................
> 2B130560560: 02 00 00 00 FF 78 00 00 - 00 00 00 00 00 00 00 00 .....x..........
> 2B130560570: 00 00 00 00 04 00 00 00 - D4 DD EB 54 00 00 00 00 ...........T....
> 2B130560580: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 2B130560590: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 2B1305605A0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 2B1305605B0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 2B1305605C0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 2B1305605D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 2B1305605E0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
> 2B1305605F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
This one has a write timestamp of Mon Apr 04 16:02:53 EDT 2016.
So more than half of this volume is old data, possibly part of an empty
default setup. The latter part of the disk, but less than half, is more
recent data.
I don't have anything more to suggest. I don't know of any way to get
just the good data, however much, at the end of the volume without the
first half of the disk.
Sorry,
Phil
^ permalink raw reply
* Re: Cannot start array on disk
From: Bhatia Amit @ 2016-07-23 4:00 UTC (permalink / raw)
To: Phil Turmel, linux-raid@vger.kernel.org
In-Reply-To: <48687c4e-792c-7cdc-7374-3020964f1892@turmel.org>
> Hmm. I'm stumped. The only thing left that I'd try is to hexdump
> search the partition looking for an ext4 magic signature. That would
> give us a clue.
>
> { Fair warning: this doesn't often end well. }
>
> To find possible ext4 signatures, use this:
>
> hexdump -C /dev/sdc4 |egrep '^[0-9a-f]+30 .+ 53 ef' >sb.lst
>
> Not all of them will be superblocks, of course, but that will give
> addresses that can be more closely examined. Paste the first hundred or
> so matches in your reply.
Hi Phil,
Following is the output from hexdump command you suggested above. Additionally, the r-linux tool that I had used to scan the disk for files, had claimed to find superblocks at multiple locations on disk. So, after the hexdump output, I have also dumped some information from hex output of the claimed superblock region, from three locations (first, middle and last superblock) on disk. Also, each superblock is claimed to occupy 2 sectors, but I have only pasted the first sector here, because the second sector is all zeros. The first two superblocks look to be exactly the same, but the last one seems a little different.
Thanks,
Amit
$ sudo hexdump -C /dev/sdc4 |egrep '^[0-9a-f]+30 .+ 53 ef' >sb.lst
^C
$ cat sb.lst
105bf330 c7 c2 ed 89 e6 42 12 cf 53 ef 9a 71 0b b5 90 48 |.....B..S..q...H|
10f66530 98 d5 99 9c fa f1 f2 22 53 ef 42 bb db 27 7d 71 |......."S.B..'}q|
110ec130 b8 39 a0 79 5a 1c 62 c8 53 ef b1 e4 46 a4 91 07 |.9.yZ.b.S...F...|
127ab030 e4 74 55 04 d1 e1 82 0d 53 ef f4 d6 cf 70 a1 86 |.tU.....S....p..|
132fb230 11 e6 63 f9 19 5b 1d d4 53 ef a1 8e c1 6f 57 48 |..c..[..S....oWH|
13ad2d30 eb 4c 2e 55 6b 97 74 41 53 ef 46 44 0d 63 d9 7e |.L.Uk.tAS.FD.c.~|
15c01f30 d4 1e 67 0c 30 40 a4 c6 53 ef 4e e8 36 f4 e9 bd |..g.0@..S.N.6...|
15de7730 4c fa 94 59 e5 bd b6 b2 53 ef f4 0f c7 78 78 0e |L..Y....S....xx.|
16ecd230 75 3d a7 28 81 0a c6 73 53 ef 96 2a d7 10 ae cc |u=.(...sS..*....|
18307f30 40 a5 5f 2a ec 1c 56 d0 53 ef 28 d7 d9 8d b4 f4 |@._*..V.S.(.....|
187eab30 f7 1b 1e e5 5e 83 28 37 53 ef b7 b4 42 13 c1 0c |....^.(7S...B...|
192f3030 e7 73 5a 17 5e 11 21 a5 53 ef 05 8f bd 5d 2d 92 |.sZ.^.!.S....]-.|
1d28de30 32 33 bd 1c b7 10 e6 78 53 ef 88 a5 9b 88 b6 50 |23.....xS......P|
2129fe30 1b 0e 6d 27 46 04 da 81 53 ef 58 14 15 09 58 45 |..m'F...S.X...XE|
2326d730 7f fc 78 d3 55 d6 12 ac 53 ef 73 67 80 15 15 70 |..x.U...S.sg...p|
23b56d30 4f 9c 76 9c e8 17 86 a3 53 ef 78 1b 58 e2 e2 47 |O.v.....S.x.X..G|
2624bd30 ad 07 ec 2d e8 db 0a 30 53 ef 65 c0 90 11 3e 1b |...-...0S.e...>.|
26afc630 fd 35 c8 6d fc f1 13 17 53 ef 61 44 7e 1b d2 ca |.5.m....S.aD~...|
27db4b30 02 d8 79 1e 76 7c 93 14 53 ef 9a f8 77 62 0a 7e |..y.v|..S...wb.~|
27dece30 a3 8f 27 a4 c2 f4 96 3a 53 ef 3a 3a 71 df 44 e8 |..'....:S.::q.D.|
2a925930 fa f1 c4 dd 01 77 d0 34 53 ef 40 71 42 e0 75 0c |.....w.4S.@qB.u.|
2c3cec30 92 76 09 be ad c8 47 86 53 ef 72 16 57 4d 81 cb |.v....G.S.r.WM..|
2c400f30 24 cb 98 10 3c d0 f3 d5 53 ef 53 d4 b3 e1 63 e6 |$...<...S.S...c.|
2cdc8c30 16 81 f1 14 36 ec d6 cc 53 ef 73 64 f5 ea 5d 5d |....6...S.sd..]]|
2d6f1630 f0 bf e7 bb 29 ad f2 0d 53 ef ba 32 a0 68 84 74 |....)...S..2.h.t|
2e9c2330 db e8 f5 ed f5 12 26 f6 53 ef f3 d6 61 c0 26 e3 |......&.S...a.&.|
2faf0830 9c 68 d2 d1 f7 fa 15 0d 53 ef 63 21 da d1 0e 8b |.h......S.c!....|
32f30930 35 23 2d 12 64 67 2c 54 53 ef d8 fa 36 2c 95 f2 |5#-.dg,TS...6,..|
f90ba830 91 88 98 6e f4 19 e1 c4 53 ef a9 fc b1 52 b1 97 |...n....S....R..|
f91c6530 bc 30 41 c1 8c 1b 8c a8 53 ef 94 a9 9b f0 8e 56 |.0A.....S......V|
fa245930 a4 66 34 9c 70 bc 44 70 53 ef 32 d5 46 fa 3c aa |.f4.p.DpS.2.F.<.|
fb143c30 b1 13 45 db d6 19 00 ec 53 ef fd 49 a5 7f b0 e8 |..E.....S..I....|
fc20f030 33 e1 02 bf cc ee 1f 93 53 ef 2b 4a ff 3e fc e3 |3.......S.+J.>..|
fcd6be30 3f 36 8c bf 11 8e 17 c3 53 ef 49 86 15 22 27 c6 |?6......S.I.."'.|
fd436f30 98 5c cc 71 7a 12 6f 15 53 ef f2 67 06 68 80 e9 |.\.qz.o.S..g.h..|
ff5b6830 fd 41 f4 49 7b 59 52 1f 53 ef 59 05 57 56 7d 89 |.A.I{YR.S.Y.WV}.|
fff80030 47 9d ba 50 03 00 1b 00 53 ef 00 00 01 00 00 00 |G..P....S.......|
1003e5030 a3 70 2a c3 b7 ff 00 a8 53 ef ff 00 e0 93 fe 2f |.p*.....S....../|
1020cdf30 b9 46 dc 14 4d c7 cc 38 53 ef 4a 0c 99 a1 cd a6 |.F..M..8S.J.....|
10629e830 19 0c 14 0e b9 ab 5f f0 53 ef 83 1e 1c f1 47 c1 |......_.S.....G.|
10801e530 81 d7 38 e9 83 5f 3b 53 53 ef b3 fa ee 8d 75 a9 |..8.._;SS.....u.|
109421e30 a9 92 47 01 f3 df 24 fa 53 ef 6c 25 7b 43 18 e1 |..G...$.S.l%{C..|
109440b30 f8 fe d1 a4 08 21 79 09 53 ef ed 4e 90 32 0d 82 |.....!y.S..N.2..|
10bc21830 0d c4 cf e6 80 36 b6 3e 53 ef de a3 82 db 73 99 |.....6.>S.....s.|
10c4bef30 8c 46 79 e3 8e 95 c1 5b 53 ef f0 0f df b1 62 29 |.Fy....[S.....b)|
10e0edd30 0d 70 ad 87 da e0 9e 7a 53 ef a4 95 67 48 dd 63 |.p.....zS...gH.c|
111dfc630 dd 2e 72 ce 16 59 24 8d 53 ef 7f c0 eb f4 0a d5 |..r..Y$.S.......|
1131ea130 b2 8d 82 ec b9 56 db bd 53 ef 2f bf a5 29 b6 45 |.....V..S./..).E|
1133f4e30 e1 8e 42 0e 82 be 56 0b 53 ef 65 ac ae 67 5c 59 |..B...V.S.e..g\Y|
11401ff30 49 36 31 43 b4 f5 53 d4 53 ef 25 fb 3d a1 11 31 |I61C..S.S.%.=..1|
1145c1530 a0 86 2f 29 db 6e d6 cf 53 ef 4b 9d 91 b3 cc 4a |../).n..S.K....J|
1146b0930 6d e2 6b 58 91 a6 58 6e 53 ef 44 4f de af 33 37 |m.kX..XnS.DO..37|
114a2b430 89 21 93 70 45 0b 8f 4c 53 ef 35 0b 6d 32 ca 5b |.!.pE..LS.5.m2.[|
115032330 66 45 5d 92 65 19 93 f9 53 ef 95 e2 b6 1e 46 d5 |fE].e...S.....F.|
115205730 7e 64 6e 08 dd f2 ed 01 53 ef d4 73 25 2d 49 9f |~dn.....S..s%-I.|
1165ed030 39 00 1a 69 2c d2 3c db 53 ef 60 00 6b f2 28 3b |9..i,.<.S.`.k.(;|
1185acd30 d1 98 5b f7 6a 0e 13 6f 53 ef 51 6a 06 37 75 8c |..[.j..oS.Qj.7u.|
11984b230 18 f4 ab 40 fa 55 90 5e 53 ef 57 c1 ad 0c cb e0 |...@.U.^S.W.....|
11c077930 00 d7 af 14 c0 1c 93 cf 53 ef 5d b0 89 9c e5 76 |........S.]....v|
11c38ff30 33 cf 3c c5 c9 f9 87 e7 53 ef 5c f5 14 00 f0 e3 |3.<.....S.\.....|
11db89230 61 c0 1f 9f a8 e6 ff 00 53 ef 5d 7a 83 ac a8 6c |a.......S.]z...l|
11e947c30 e6 6d e0 55 51 d6 cb 9c 53 ef 98 0f 55 6e fe b8 |.m.UQ...S...Un..|
11eadce30 8b 7d 71 7c 1c 0f ad c1 53 ef a0 1d 65 66 fa 06 |.}q|....S...ef..|
11f485430 5e 2f 5a 2b 48 69 62 44 53 ef 65 d5 06 a0 29 a2 |^/Z+HibDS.e...).|
11fc23030 a9 97 1f b7 75 ef f6 45 53 ef f6 f5 59 d2 4f 25 |....u..ES...Y.O%|
1248a2b30 63 b9 43 b5 5d 4e e8 47 53 ef ed 4b e6 06 52 e0 |c.C.]N.GS..K..R.|
127ad8830 a5 9c 2a 44 50 2f f0 0f 53 ef cf eb 57 46 37 d4 |..*DP/..S...WF7.|
129bc9630 04 04 01 01 01 01 04 02 53 ef 2f 57 69 6e 64 6f |........S./Windo|
12a04da30 4e 68 f3 63 2a ab 18 d8 53 ef 7b d6 36 be c5 a6 |Nh.c*...S.{.6...|
12b8a2b30 59 ab c2 61 49 da 68 2b 53 ef 8b 13 03 e5 f7 02 |Y..aI.h+S.......|
12d963530 92 cd 5e 5f 0d 56 8e 4b 53 ef a7 13 b2 64 a0 d2 |..^_.V.KS....d..|
12dba1330 ff df 64 ae f0 b0 b6 f7 53 ef 97 06 ff 92 9b 82 |..d.....S.......|
12de94f30 88 85 59 bb 88 5f 50 58 53 ef 18 af 98 14 c1 62 |..Y.._PXS......b|
12e2d6930 d0 26 8c 44 8a 91 9e 2e 53 ef 9b 1e f8 af a6 70 |.&.D....S......p|
12f111030 23 df 68 37 78 f3 ad bb 53 ef 73 61 37 81 56 54 |#.h7x...S.sa7.VT|
12f4f4430 40 ba 7d 05 40 3d f0 82 53 ef 21 a8 f3 a8 bc 7d |@.}.@=..S.!....}|
12fd32030 fa 67 9f b2 bc 4c 6d b0 53 ef 05 62 62 32 93 81 |.g...Lm.S..bb2..|
130852230 e9 fa c8 0c af 14 93 bd 53 ef 33 ee 09 61 1e 6b |........S.3..a.k|
1323fd330 7d 4e cb 58 78 ca 8d e1 53 ef 12 f6 ee 19 68 46 |}N.Xx...S.....hF|
132ae3b30 50 35 42 46 d9 bf af a0 53 ef 6c dd 82 8b c4 ce |P5BF....S.l.....|
132c99830 38 69 aa 62 1d ce 64 7b 53 ef 77 fe 80 59 f4 35 |8i.b..d{S.w..Y.5|
133d49730 1a 48 8a 29 f6 1a 68 c8 53 ef 65 17 6f 78 9d f7 |.H.)..h.S.e.ox..|
1345ed230 01 71 89 16 36 c4 b0 26 53 ef 66 9f 02 f6 39 1b |.q..6..&S.f...9.|
13490ec30 95 03 fb 23 62 06 9b 5b 53 ef 1c 9a 24 6e 2b c3 |...#b..[S...$n+.|
135bc7930 c8 4d 9d 4e 5e 24 9a 33 53 ef b7 4f 56 6c 9f c7 |.M.N^$.3S..OVl..|
13efd6e30 09 03 03 03 02 99 42 19 53 ef 09 03 03 03 02 99 |......B.S.......|
1433a1630 19 bb 0a 03 04 03 54 83 53 ef 1d 19 bc 0a 03 04 |......T.S.......|
1529e6f30 12 0f bc 17 8f 9f 1a 48 53 ef 5c 2b b1 1f df 73 |.......HS.\+...s|
157810530 65 49 0b 1d 4a 68 08 00 53 ef 8f e3 37 97 7d 78 |eI..Jh..S...7.}x|
157a38730 7f c0 98 96 b4 cf ea 3a 53 ef 59 c8 e0 72 d7 c4 |.......:S.Y..r..|
15a696530 41 ab e4 ce 11 c6 14 9e 53 ef b9 7b 0d c7 23 ee |A.......S..{..#.|
15b0bb230 71 e4 7f 75 89 9f 49 5c 53 ef bf e5 84 21 7b a9 |q..u..I\S....!{.|
15b3cfc30 d3 a3 15 81 14 01 89 a0 53 ef e4 0c c1 9b e0 09 |........S.......|
15e5c2e30 51 0c d3 53 dd 7f 5b e7 53 ef 7b 4e fe d0 9c 39 |Q..S..[.S.{N...9|
15f417c30 66 b6 00 ca ca 90 2d ae 53 ef 47 aa eb 68 18 30 |f.....-.S.G..h.0|
1611a6530 ad e5 c0 08 7e 9f 1f 02 53 ef d6 d5 f3 df 6e f6 |....~...S.....n.|
167671330 6c 00 2c 17 f7 94 11 00 53 ef d3 61 00 28 16 47 |l.,.....S..a.(.G|
168ad2730 9f 7a 9a 77 da 7f a9 bf 53 ef 9d 74 be b5 36 ef |.z.w....S..t..6.|
1696ba630 e2 e9 32 48 30 b8 c9 4b 53 ef 8b 58 2e 9d 24 09 |..2H0..KS..X..$.|
16b326930 5f 01 e6 7c 20 c9 39 be 53 ef 69 08 f5 d1 ee 86 |_..| .9.S.i.....|
16b431830 40 64 66 38 0c 06 15 ba 53 ef de bd d3 ee fb 7e |@df8....S......~|
1706ca530 3a e1 b9 b2 e1 4d d4 00 53 ef f0 45 c8 4e ce 33 |:....M..S..E.N.3|
170cd5230 c6 7e dd 7d a0 21 80 2d 53 ef 9d b1 09 d4 ea aa |.~.}.!.
$ cat sblock.txt
Name: Ext2/Ext3/Ext4 SuperBlock
Offset (in sectors): 8387584
Size (in sectors): 2
Sector 8387584 (Parent: WDC WD30EZRX-00D8PB0 80.00A80 Record: 17419264)
FFF80000: 00 46 B7 02 5F 8C B9 02 - 00 00 00 00 62 25 B6 02 .F.._.......b%..
FFF80010: 1A 3B B7 02 00 00 00 00 - 06 00 00 00 06 00 00 00 .;..............
FFF80020: F8 FF 00 00 F8 FF 00 00 - 00 FF 00 00 43 3E B3 4F ............C>.O
FFF80030: 47 9D BA 50 03 00 1B 00 - 53 EF 00 00 01 00 00 00 G..P....S.......
FFF80040: 3B B5 02 00 00 4E ED 00 - 00 00 00 00 01 00 00 00 ;....N..........
FFF80050: 00 00 00 00 0B 00 00 00 - 00 01 01 00 3C 00 00 00 ............<...
FFF80060: 42 02 00 00 7B 00 00 00 - B6 7F 9F FD 12 BF 4D 57 B...{.........MW
FFF80070: A8 34 DD 09 E9 E8 BA C0 - 00 00 00 00 00 00 00 00 .4..............
FFF80080: 00 00 00 00 00 00 00 00 - 2F 43 61 63 68 65 56 6F ......../CacheVo
FFF80090: 6C 75 6D 65 00 C8 24 9E - 20 22 82 24 22 C8 1B 60 lume..$. ".$"..`
FFF800A0: 60 FF FF FF 9C CA D0 E4 - 5C C8 13 41 80 C0 10 E6 `.......\..A....
FFF800B0: 68 C8 08 21 60 CA D0 E4 - 5C 00 00 00 00 CD AC 46 h..!`...\......F
FFF800C0: 80 C8 1C 5A 60 C8 24 9E - 00 00 00 00 00 00 20 00 ...Z`.$....... .
FFF800D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
FFF800E0: 08 00 00 00 00 00 00 00 - 00 00 00 00 FC ED 10 2F .............../
FFF800F0: 38 44 66 85 D0 AC 7C A3 - FF F3 B0 AF 01 01 00 00 8Df...|.........
FFF80100: 00 00 00 00 00 00 00 00 - 3B B5 02 00 0A F3 02 00 ........;.......
FFF80110: 04 00 00 00 00 00 00 00 - 00 00 00 00 FF 7F 00 00 ................
FFF80120: 78 EA B0 02 FF 7F 00 00 - 01 00 00 00 77 6A B1 02 x...........wj..
FFF80130: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
FFF80140: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 80 ................
FFF80150: 00 00 00 00 00 00 00 00 - 00 00 00 00 1C 00 1C 00 ................
FFF80160: 02 00 00 00 FF 78 00 00 - 00 00 00 00 00 00 00 00 .....x..........
FFF80170: 00 00 00 00 04 00 00 00 - 94 F3 87 01 00 00 00 00 ................
FFF80180: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
FFF80190: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
FFF801A0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
FFF801B0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
FFF801C0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
FFF801D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
FFF801E0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
FFF801F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
Name: Ext2/Ext3/Ext4 SuperBlock
Offset (in sectors): 2038182912
Size (in sectors): 2
Sector 2038182912 (Parent: WDC WD30EZRX-00D8PB0 80.00A80 Record: 2047214592)
F2F8680000: 00 46 B7 02 5F 8C B9 02 - 00 00 00 00 62 25 B6 02 .F.._.......b%..
F2F8680010: 1A 3B B7 02 00 00 00 00 - 06 00 00 00 06 00 00 00 .;..............
F2F8680020: F8 FF 00 00 F8 FF 00 00 - 00 FF 00 00 43 3E B3 4F ............C>.O
F2F8680030: 47 9D BA 50 03 00 1B 00 - 53 EF 00 00 01 00 00 00 G..P....S.......
F2F8680040: 3B B5 02 00 00 4E ED 00 - 00 00 00 00 01 00 00 00 ;....N..........
F2F8680050: 00 00 00 00 0B 00 00 00 - 00 01 F3 00 3C 00 00 00 ............<...
F2F8680060: 42 02 00 00 7B 00 00 00 - B6 7F 9F FD 12 BF 4D 57 B...{.........MW
F2F8680070: A8 34 DD 09 E9 E8 BA C0 - 00 00 00 00 00 00 00 00 .4..............
F2F8680080: 00 00 00 00 00 00 00 00 - 2F 43 61 63 68 65 56 6F ......../CacheVo
F2F8680090: 6C 75 6D 65 00 C8 24 9E - 20 22 82 24 22 C8 1B 60 lume..$. ".$"..`
F2F86800A0: 60 FF FF FF 9C CA D0 E4 - 5C C8 13 41 80 C0 10 E6 `.......\..A....
F2F86800B0: 68 C8 08 21 60 CA D0 E4 - 5C 00 00 00 00 CD AC 46 h..!`...\......F
F2F86800C0: 80 C8 1C 5A 60 C8 24 9E - 00 00 00 00 00 00 20 00 ...Z`.$....... .
F2F86800D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
F2F86800E0: 08 00 00 00 00 00 00 00 - 00 00 00 00 FC ED 10 2F .............../
F2F86800F0: 38 44 66 85 D0 AC 7C A3 - FF F3 B0 AF 01 01 00 00 8Df...|.........
F2F8680100: 00 00 00 00 00 00 00 00 - 3B B5 02 00 0A F3 02 00 ........;.......
F2F8680110: 04 00 00 00 00 00 00 00 - 00 00 00 00 FF 7F 00 00 ................
F2F8680120: 78 EA B0 02 FF 7F 00 00 - 01 00 00 00 77 6A B1 02 x...........wj..
F2F8680130: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
F2F8680140: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 80 ................
F2F8680150: 00 00 00 00 00 00 00 00 - 00 00 00 00 1C 00 1C 00 ................
F2F8680160: 02 00 00 00 FF 78 00 00 - 00 00 00 00 00 00 00 00 .....x..........
F2F8680170: 00 00 00 00 04 00 00 00 - 94 F3 87 01 00 00 00 00 ................
F2F8680180: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
F2F8680190: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
F2F86801A0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
F2F86801B0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
F2F86801C0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
F2F86801D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
F2F86801E0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
F2F86801F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
Name: Ext2/Ext3/Ext4 SuperBlock
Offset (in sectors): 5781334786
Size (in sectors): 2
Sector 5781334786 (Parent: WDC WD30EZRX-00D8PB0 80.00A80 Record: 5790366466)
2B130560400: 00 46 B7 02 5F 8C B9 02 - 00 00 00 00 25 7F 09 02 .F.._.......%...
2B130560410: DC F8 99 02 00 00 00 00 - 06 00 00 00 06 00 00 00 ................
2B130560420: F8 FF 00 00 F8 FF 00 00 - 00 FF 00 00 6D C8 02 57 ............m..W
2B130560430: 6D C8 02 57 2E 00 1B 00 - 53 EF 01 00 01 00 00 00 m..W....S.......
2B130560440: 3B B5 02 00 00 4E ED 00 - 00 00 00 00 01 00 00 00 ;....N..........
2B130560450: 00 00 00 00 0B 00 00 00 - 00 01 00 00 3C 00 00 00 ............<...
2B130560460: 46 02 00 00 7B 00 00 00 - B6 7F 9F FD 12 BF 4D 57 F...{.........MW
2B130560470: A8 34 DD 09 E9 E8 BA C0 - 00 00 00 00 00 00 00 00 .4..............
2B130560480: 00 00 00 00 00 00 00 00 - 2F 43 61 63 68 65 56 6F ......../CacheVo
2B130560490: 6C 75 6D 65 00 C7 4B BE - 20 24 82 24 82 C8 1B A0 lume..K. $.$....
2B1305604A0: 60 FF FF FF 9C C0 F1 11 - DC C8 13 2A A0 C0 10 E6 `..........*....
2B1305604B0: 68 C8 08 21 60 C0 F1 11 - DC 00 00 00 00 CF 3D 2A h..!`.........=*
2B1305604C0: E0 C2 94 C1 60 C7 4B BE - 00 00 00 00 00 00 20 00 ....`.K....... .
2B1305604D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
2B1305604E0: 08 00 00 00 00 00 00 00 - 00 00 00 00 FC ED 10 2F .............../
2B1305604F0: 38 44 66 85 D0 AC 7C A3 - FF F3 B0 AF 01 01 00 00 8Df...|.........
2B130560500: 00 00 00 00 00 00 00 00 - 3B B5 02 00 0A F3 02 00 ........;.......
2B130560510: 04 00 00 00 00 00 00 00 - 00 00 00 00 FF 7F 00 00 ................
2B130560520: 78 EA B0 02 FF 7F 00 00 - 01 00 00 00 77 6A B1 02 x...........wj..
2B130560530: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
2B130560540: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 80 ................
2B130560550: 00 00 00 00 00 00 00 00 - 00 00 00 00 1C 00 1C 00 ................
2B130560560: 02 00 00 00 FF 78 00 00 - 00 00 00 00 00 00 00 00 .....x..........
2B130560570: 00 00 00 00 04 00 00 00 - D4 DD EB 54 00 00 00 00 ...........T....
2B130560580: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
2B130560590: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
2B1305605A0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
2B1305605B0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
2B1305605C0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
2B1305605D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
2B1305605E0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
2B1305605F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
^ permalink raw reply
* Re: Cannot start array on disk
From: Phil Turmel @ 2016-07-22 14:48 UTC (permalink / raw)
To: Bhatia Amit, linux-raid@vger.kernel.org
In-Reply-To: <1334935791.2305089.1469066429563.JavaMail.yahoo@mail.yahoo.com>
On 07/20/2016 10:00 PM, Bhatia Amit wrote:
>
>
>> I'm not sure if this is supported, by try specifying the version along
>> with --examine for each of v0.90, v1.0, v1.1, and v1.2 to see if any
>> difference shows. Paste the results from each.
>
>
> Hi Phil
>
> Only metadata v1.0 seems to be valid for sdc4.
Hmm. I'm stumped. The only thing left that I'd try is to hexdump
search the partition looking for an ext4 magic signature. That would
give us a clue.
{ Fair warning: this doesn't often end well. }
To find possible ext4 signatures, use this:
hexdump -C /dev/sdc4 |egrep '^[0-9a-f]+30 .+ 53 ef' >sb.lst
Not all of them will be superblocks, of course, but that will give
addresses that can be more closely examined. Paste the first hundred or
so matches in your reply.
Phil
^ permalink raw reply
* Re: Recovering RAID Volumes from 6 Disks
From: Phil Turmel @ 2016-07-22 13:56 UTC (permalink / raw)
To: Wols Lists, Roman Mamedov; +Cc: Amit Biswas, linux-raid
In-Reply-To: <578FA277.7030001@youngman.org.uk>
On 07/20/2016 12:10 PM, Wols Lists wrote:
> On 20/07/16 16:36, Wols Lists wrote:
>> Get that first 3TB drive. NOW. Physically replace sda in the machine,
>> and configure it as a single-drive mirror ( --create --devices=2 sda
>> spare).
>
> Just noticed your edu address. If Phil Turmel chimes in, he'll tell me
> off for telling you to spend money :-)
No, not this time. :-)
I would also note that the raid1 composed of the six sd?2 partitions is
only operating as a two-copy mirror -- the other four devices are
spares. Whoever created that array added the extra drives but never
used --grow to set the number of mirrors to six.
Amit, as soon as you get your arrays assembled with the --force option,
follow Wol's advice on rsync'ing to a new array. I wouldn't advise
trying to fix the UREs on your existing arrays since there are so many
that you'd certainly trip the 10/hr read error limit in MD.
Just copying data may also trip the read error rate limit, but you have
no choice. If it happens and kicks out any array devices, simply stop
the rsync, stop and re-assemble the array (with --force), and continue
with rsync.
The Constellations can probably be recycled into spares or backup
devices after you copy your data. I didn't look close at their stats.
Phil
^ permalink raw reply
* Re: How does md gurantee not miss to free an active stripe_head when md stops?
From: NeilBrown @ 2016-07-22 1:15 UTC (permalink / raw)
To: Vaughan; +Cc: linux-raid
In-Reply-To: <004e01d1e274$faa33a20$efe9ae60$@163.com>
[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
On Wed, Jul 20 2016, Vaughan wrote:
> Hi Neil,
>
> I'm using v3.10 md code for develop. Recently I encounter a problem where an
> read IO usually returned from physical disk after md has been stopped.
> I reviewed the code and find when md stops, it unregister raid5d
> unconditionally and call shrink_stripes() to free only the *inactive*
> stripes.
> I know before stop, it uses O_EXCL open the md, but that won't stop others
> open it and send IO to it.
> So I think it's possible that some active stripes will be still running.
do_md_stop() calls sync_blockdev() which was supposed to wait for all
outstanding IO. It probably doesn't wait for reads though, only writes.
>
> And I also found
> commit 5aa61f427e4979be733e4847b9199ff9cc48a47e
> Author: NeilBrown <neilb@suse.de>
> Date: Mon Dec 15 12:56:57 2014 +1100
> md: split detach operation out from ->stop.
>
> add calling a quiesce before unregister raid5d in __md_stop, which not
> exists there before.
> Does this fix the hole when md stop?
Why don't you try it and see?
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion
From: Eric Wheeler @ 2016-07-21 22:53 UTC (permalink / raw)
To: Lars Ellenberg
Cc: Mike Snitzer, NeilBrown, Jens Axboe, linux-block,
Martin K. Petersen, Peter Zijlstra, Jiri Kosina, Ming Lei,
Kirill A. Shutemov, linux-kernel, linux-raid, Takashi Iwai,
linux-bcache, Zheng Liu, Kent Overstreet, Keith Busch, dm-devel,
Shaohua Li, Ingo Molnar, Alasdair Kergon, Roland Kammerer,
Mikulas Patocka, Jeff Moyer
In-Reply-To: <20160719090024.GB20868@soda.linbit>
[+cc Mikulas Patocka, Jeff Moyer; Do either of you have any input on Lars'
commentary related to patchwork #'s 9204125 and 7398411 and BZ#119841? ]
On Tue, 19 Jul 2016, Lars Ellenberg wrote:
> On Tue, Jul 12, 2016 at 10:32:33PM -0400, Mike Snitzer wrote:
> > On Tue, Jul 12 2016 at 10:18pm -0400,
> > Eric Wheeler <bcache@lists.ewheeler.net> wrote:
> >
> > > On Tue, 12 Jul 2016, NeilBrown wrote:
> > >
> > > > On Tue, Jul 12 2016, Lars Ellenberg wrote:
> > > > ....
> > > > >
> > > > > Instead, I suggest to distinguish between recursive calls to
> > > > > generic_make_request(), and pushing back the remainder part in
> > > > > blk_queue_split(), by pointing current->bio_lists to a
> > > > > struct recursion_to_iteration_bio_lists {
> > > > > struct bio_list recursion;
> > > > > struct bio_list queue;
> > > > > }
> > > > >
> > > > > By providing each q->make_request_fn() with an empty "recursion"
> > > > > bio_list, then merging any recursively submitted bios to the
> > > > > head of the "queue" list, we can make the recursion-to-iteration
> > > > > logic in generic_make_request() process deepest level bios first,
> > > > > and "sibling" bios of the same level in "natural" order.
> > > > >
> > > > > Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
> > > > > Signed-off-by: Roland Kammerer <roland.kammerer@linbit.com>
> > > >
> > > > Reviewed-by: NeilBrown <neilb@suse.com>
> > > >
> > > > Thanks again for doing this - I think this is a very significant
> > > > improvement and could allow other simplifications.
> > >
> > > Thank you Lars for all of this work!
> > >
> > > It seems like there have been many 4.3+ blockdev stacking issues and this
> > > will certainly address some of those (maybe all of them?). (I think we
> > > hit this while trying drbd in 4.4 so we dropped back to 4.1 without
> > > issue.) It would be great to hear 4.4.y stable pick this up if
> > > compatible.
> > >
> > >
> > > Do you believe that this patch would solve any of the proposals by others
> > > since 4.3 related to bio splitting/large bios? I've been collecting a
> > > list, none of which appear have landed yet as of 4.7-rc7 (but correct me
> > > if I'm wrong):
> > >
> > > A. [PATCH v2] block: make sure big bio is splitted into at most 256 bvecs
> > > by Ming Lei: https://patchwork.kernel.org/patch/9169483/
>
> That's an independend issue.
>
> > > B. block: don't make BLK_DEF_MAX_SECTORS too big
> > > by Shaohua Li: http://www.spinics.net/lists/linux-bcache/msg03525.html
>
> Yet an other independend issue.
>
> > > C. [1/3] block: flush queued bios when process blocks to avoid deadlock
> > > by Mikulas Patocka: https://patchwork.kernel.org/patch/9204125/
> > > (was https://patchwork.kernel.org/patch/7398411/)
>
> As it stands now,
> this is yet an other issue, but related.
>
> From the link above:
>
> | ** Here is the dm-snapshot deadlock that was observed:
> |
> | 1) Process A sends one-page read bio to the dm-snapshot target. The bio
> | spans snapshot chunk boundary and so it is split to two bios by device
> | mapper.
> |
> | 2) Device mapper creates the first sub-bio and sends it to the snapshot
> | driver.
> |
> | 3) The function snapshot_map calls track_chunk (that allocates a
> | structure
> | dm_snap_tracked_chunk and adds it to tracked_chunk_hash) and then remaps
> | the bio to the underlying device and exits with DM_MAPIO_REMAPPED.
> |
> | 4) The remapped bio is submitted with generic_make_request, but it isn't
> | issued - it is added to current->bio_list instead.
> |
> | 5) Meanwhile, process B (dm's kcopyd) executes pending_complete for the
> | chunk affected be the first remapped bio, it takes down_write(&s->lock)
> | and then loops in __check_for_conflicting_io, waiting for
> | dm_snap_tracked_chunk created in step 3) to be released.
> |
> | 6) Process A continues, it creates a second sub-bio for the rest of the
> | original bio.
>
> Aha.
> Here is the relation.
> If "A" had only ever processed "just the chunk it can handle now",
> and "pushed back" the rest of the incoming bio,
> it could rely on all deeper level bios to have been submitted already.
>
> But this does not look like it easily fits into the current DM model.
>
> | 7) snapshot_map is called for this new bio, it waits on
> | down_write(&s->lock) that is held by Process B (in step 5).
>
> There is an other suggestion:
> Use down_trylock (or down_timeout),
> and if it fails, push back the currently to-be-processed bio.
> We can introduce a new bio helper for that.
> Kind of what blk_queue_split() does with my patch applied.
>
> Or even better, ignore the down_trylock suggestion,
> simply not iterate over all pieces first,
> but process one piece, and return back the the
> iteration in generic_make_request.
>
> A bit of conflict here may be that DM has all its own
> split and clone and queue magic, and wants to process
> "all of the bio" before returning back to generic_make_request().
>
> To change that, __split_and_process_bio() and all its helpers
> would need to learn to "push back" (pieces of) the bio they are
> currently working on, and not push back via "DM_ENDIO_REQUEUE",
> but by bio_list_add_head(¤t->bio_lists->queue, piece_to_be_done_later).
>
> Then, after they processed each piece,
> *return* all the way up to the top-level generic_make_request(),
> where the recursion-to-iteration logic would then
> make sure that all deeper level bios, submitted via
> recursive calls to generic_make_request() will be processed, before the
> next, pushed back, piece of the "original incoming" bio.
>
> And *not* do their own iteration over all pieces first.
>
> Probably not as easy as dropping the while loop,
> using bio_advance, and pushing that "advanced" bio back to
> current->...queue?
>
> static void __split_and_process_bio(struct mapped_device *md,
> struct dm_table *map, struct bio *bio)
> ...
> ci.bio = bio;
> ci.sector_count = bio_sectors(bio);
> while (ci.sector_count && !error)
> error = __split_and_process_non_flush(&ci);
> ...
> error = __split_and_process_non_flush(&ci);
> if (ci.sector_count)
> bio_advance()
> bio_list_add_head(¤t->bio_lists->queue, )
> ...
>
> Something like that, maybe?
> Just a thought.
>
> > > D. dm-crypt: Fix error with too large bios
> > > by Mikulas Patocka: https://patchwork.kernel.org/patch/9138595/
> > >
> > > The A,B,D are known to fix large bio issues when stacking dm+bcache
> > > (though the B,D are trivial and probably necessary even with your patch).
> > >
> > > Patch C was mentioned earlier in this thread by Mike Snitzer and you
> > > commented briefly that his patch might solve the issue; given that, and in
> > > the interest of minimizing duplicate effort, which of the following best
> > > describes the situation?
> > >
> > > 1. Your patch could supersede Mikulas's patch; they address the same
> > > issue.
> > >
> > > 2. Mikulas's patch addresses different issues such and both patches
> > > should be applied.
> > >
> > > 3. There is overlap between both your patch and Mikulas's such that both
> > > #1,#2 are true and effort to solve this has been duplicated.
> > >
> > >
> > > If #3, then what might be done to resolve the overlap?
> >
> > Mikulas confirmed to me that he believes Lars' v2 patch will fix the
> > dm-snapshot problem, which is being tracked with this BZ:
> > https://bugzilla.kernel.org/show_bug.cgi?id=119841
> >
> > We'll see how testing goes (currently underway).
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] mdcheck: Send progress messages to system log
From: Jes Sorensen @ 2016-07-21 15:53 UTC (permalink / raw)
To: Bill Merriam; +Cc: linux-raid, NeilBrown
In-Reply-To: <1463497979.31691.7.camel@billmerriam.com>
Bill Merriam <lists@billmerriam.com> writes:
> From 03bec5cfdd87f25b1669a4b62d19cf872403d37a Mon Sep 17 00:00:00 2001
> From: Bill Merriam <bill@merriam.net>
> Date: Tue, 17 May 2016 10:16:13 -0400
> Subject: [PATCH] The mdcheck script now adds messages to the system log
> to
> report on progress of the array check. These are issued when mdcheck
> starts
> or continues a check and when it suspends a check at the expiration of
> duration. The messages either report the check has completed or the
> block
> number of the current and last block in the array and the percentage of
> completion.
>
> Signed-off-by: Bill Merriam <bill@merriam.net>
> ---
> misc/mdcheck | 7 +++++++
> 1 file changed, 7 insertions(+)
Bill,
Principle of patch looks fine, but the formatting is all messed
up. Could you please try to clean it up a bit and resend it? If your
mail client auto-wraps it, please try sending it as an attachment.
In general code and comments should stay within 80 characters as with
the kernel.
Sorry for the late response, I missed your posting as I was traveling at
the time. Thanks to Neil for nagged me about it.
Cheers,
Jes
>
> diff --git a/misc/mdcheck b/misc/mdcheck
> index 2c8f54d..c33e3f6 100644
> --- a/misc/mdcheck
> +++ b/misc/mdcheck
> @@ -100,6 +100,8 @@ do
> continue
> else
> start=`cat "$fl"`
> + size=$(expr $(cat $sys/md/component_size) \* 2)
> + logger $(echo $dev $start $size | awk '{printf "MDCHECK Continuing
> check on %s at block %i of %i, %6.2f%% complete\n", $1, $2, $3,
> $2/$3*100 }')
> fi
>
> cnt=$[cnt+1]
> @@ -129,6 +131,7 @@ do
> then
> eval MD_${i}_fl=
> rm -f $fl
> + logger "MDCHECK check completed on ${sys##*/}, removing $fl"
> continue;
> fi
> read a rest < $sys/md/sync_completed
> @@ -156,4 +159,8 @@ do
> fi
> echo idle > $sys/md/sync_action
> cat $sys/md/sync_min > $fl
> + dev=${sys##*/}
> + start=$(cat $fl)
> + size=$(expr $(cat $sys/md/component_size) \* 2)
> + logger $(echo $dev $start $size | awk '{printf "MDCHECK Suspending
> check on %s at block %i of %i, %6.2f%% complete\n", $1, $2, $3,
> $2/$3*100 }')
> done
^ permalink raw reply
* Re: [PATCH] Monitor: release /proc/mdstat fd when no arrays present
From: Jes Sorensen @ 2016-07-21 15:37 UTC (permalink / raw)
To: Tomasz Majchrzak
Cc: linux-raid, aleksey.obitotskiy, pawel.baldysiak,
artur.paszkiewicz
In-Reply-To: <1467702771-1375-1-git-send-email-tomasz.majchrzak@intel.com>
Tomasz Majchrzak <tomasz.majchrzak@intel.com> writes:
> If md kernel module is reloaded, /proc/mdstat cannot be accessed ("cat:
> /proc/mdstat: No such file or directory"). The reason is mdadm monitor
> still holds a file descriptor to previous /proc/mdstat instance. It
> leads to really confusing outcome of the following operations - mdadm
> seems to run without errors, however some udev rules don't get executed
> and new array doesn't work.
>
> Add a check if lseek was successful as it fails if md kernel module has
> been unloaded - close a file descriptor then. The problem is mdadm
> monitor doesn't always do it before next operation takes place. To
> prevent it monitor always releases /proc/mdstat descriptor when there
> are no arrays to be monitored, just in case driver unload happens in a
> moment.
>
> Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
> Reviewed-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> ---
> Monitor.c | 2 ++
> mdstat.c | 6 +++++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
Looks good, applied!
Thanks,
Jes
^ permalink raw reply
* Re: [PATCH v3] Remove: container should wait for an array to release a drive
From: Jes Sorensen @ 2016-07-21 15:26 UTC (permalink / raw)
To: Tomasz Majchrzak
Cc: linux-raid, aleksey.obitotskiy, pawel.baldysiak,
artur.paszkiewicz
In-Reply-To: <1469087982-2102-1-git-send-email-tomasz.majchrzak@intel.com>
Tomasz Majchrzak <tomasz.majchrzak@intel.com> writes:
> A 'faulty' drive is being removed from a container after it has been
> released by an array, however there is a race there. The drive is
> released asynchronously by a monitor but sometimes it doesn't happen
> before container checks it. It results in a container refusing to remove
> a drive as it still seems to be a part of some array.
>
> It seems 'ping_monitor' could be a solution here to assure monitor has
> had a chance to process the events, however it doesn't resolve the
> problem - sometimes an array has to request a release of the drive few
> times (as the array is busy) and single 'ping_monitor' call is not
> sufficient. As there is no way to query monitor progress, it forces us
> to retry a check several times before an error is returned.
>
> Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
> ---
> Manage.c | 41 ++++++++++++++++++++++++++++-------------
> 1 file changed, 28 insertions(+), 13 deletions(-)
Looks good - applied!
Thanks,
Jes
^ permalink raw reply
* [PATCH v3] Remove: container should wait for an array to release a drive
From: Tomasz Majchrzak @ 2016-07-21 7:59 UTC (permalink / raw)
To: linux-raid
Cc: Jes.Sorensen, aleksey.obitotskiy, pawel.baldysiak,
artur.paszkiewicz
A 'faulty' drive is being removed from a container after it has been
released by an array, however there is a race there. The drive is
released asynchronously by a monitor but sometimes it doesn't happen
before container checks it. It results in a container refusing to remove
a drive as it still seems to be a part of some array.
It seems 'ping_monitor' could be a solution here to assure monitor has
had a chance to process the events, however it doesn't resolve the
problem - sometimes an array has to request a release of the drive few
times (as the array is busy) and single 'ping_monitor' call is not
sufficient. As there is no way to query monitor progress, it forces us
to retry a check several times before an error is returned.
Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
---
Manage.c | 41 ++++++++++++++++++++++++++++-------------
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/Manage.c b/Manage.c
index e2e88b8..33e343d 100644
--- a/Manage.c
+++ b/Manage.c
@@ -1125,19 +1125,34 @@ int Manage_remove(struct supertype *tst, int fd, struct mddev_dev *dv,
*/
if (rdev == 0)
ret = -1;
- else
- ret = sysfs_unique_holder(devnm, rdev);
- if (ret == 0) {
- pr_err("%s is not a member, cannot remove.\n",
- dv->devname);
- close(lfd);
- return -1;
- }
- if (ret >= 2) {
- pr_err("%s is still in use, cannot remove.\n",
- dv->devname);
- close(lfd);
- return -1;
+ else {
+ /*
+ * The drive has already been set to 'faulty', however
+ * monitor might not have had time to process it and the
+ * drive might still have an entry in the 'holders'
+ * directory. Try a few times to avoid a false error
+ */
+ int count = 20;
+
+ do {
+ ret = sysfs_unique_holder(devnm, rdev);
+ if (ret < 2)
+ break;
+ usleep(100 * 1000); /* 100ms */
+ } while (--count > 0);
+
+ if (ret == 0) {
+ pr_err("%s is not a member, cannot remove.\n",
+ dv->devname);
+ close(lfd);
+ return -1;
+ }
+ if (ret >= 2) {
+ pr_err("%s is still in use, cannot remove.\n",
+ dv->devname);
+ close(lfd);
+ return -1;
+ }
}
}
/* FIXME check that it is a current member */
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v4 18/21] fuse: Add support for pid namespaces
From: Miklos Szeredi @ 2016-07-21 7:25 UTC (permalink / raw)
To: Seth Forshee
Cc: Sheng Yang, Eric W. Biederman, Miklos Szeredi, Alexander Viro,
Serge Hallyn, Richard Weinberger, Austin S Hemmelgarn,
Pavel Tikhomirov, kernel list,
linux-bcache-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-fsdevel,
fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
selinux-+05T5uksL2qpZYMLLGbcSA, cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160720125201.GA52079@ubuntu-hedt>
On Wed, Jul 20, 2016 at 2:52 PM, Seth Forshee
<seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
> It sounds like we need to remove the restriction on accessing the
> filesystem from a different pid namespace. I don't think this poses a
> security problem. However there's no pid mapping that is usable by the
> userspace fuse process, so what do we put in the fuse request? Probably
> the only candidates are 0 and 0xffffffff.
>
> So a question for the fuse developers - is one value or the other
> preferrable for fuse_in_header.pid when the pid cannot be mapped, and is
> this going to cause problems for any fuse filesystems? I suspect that
> few filesystems actually look at the pid anyway, and already for a
> filesystem mounted in a pid namespace the values being given to
> userspace won't be correct for the namespace of the fuse process.
pid = 0 sounds good.
The pid from the request is used for example to get the auxiliary
group list by libfuse (fuse_req_getgroups()). That's not used by all
filesystems and it will return an error in case it can't find the proc
entry (which it won't for pid == 0).
It would be nice if we could transfer the group list through the
userspace/kernel protocol, since then it wouldn't depend on proc and
on being in the same pid namespace. But that's another story.
Thanks,
Miklos
^ permalink raw reply
* Re: dm stripe: add DAX support
From: Jens Axboe @ 2016-07-21 3:03 UTC (permalink / raw)
To: Mike Snitzer, axboe-b10kYP2dOMg
Cc: linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
In-Reply-To: <20160721000142.GA21913-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 07/20/2016 06:01 PM, Mike Snitzer wrote:
> On Wed, Jul 13 2016 at 11:03am -0400,
> Kani, Toshimitsu <toshi.kani-ZPxbGqLxI0U@public.gmane.org> wrote:
>
>> On Tue, 2016-07-12 at 22:01 -0400, Mike Snitzer wrote:
>>> On Tue, Jul 12 2016 at 6:22pm -0400,
>>> Kani, Toshimitsu <toshi.kani-ZPxbGqLxI0U@public.gmane.org> wrote:
>>>> On Fri, 2016-06-24 at 14:29 -0400, Mike Snitzer wrote:
>>>>>
>> :
>>> Thanks for putting this summary together. Unfortunately none of the DM
>>> changes can be queued for 4.8 until Jens takes the 2 block core patches:
>>> https://patchwork.kernel.org/patch/9196021/
>>> https://patchwork.kernel.org/patch/9196019/
>>>
>>> Not sure what the hold up and/or issue is with them. But I've asked
>>> twice (and implicilty a 3rd time here). Hopefully they land in time for
>>> 4.8.
>>
>> Hi Jens,
>>
>> Can you take the two patches above? These patches add QUEUE_FLAG_DAX and its
>> sysfs show func. They allow device-mapper to set dax-capability based on its
>> configuration, and also allow user applications to check dax-capability via
>> sysfs.
>
> Hi Jens,
>
> As I shared with you before, here are the 2 patches I staged in
> linux-next via linux-dm.git's 'for-next' (same as in the patchwork
> references above) -- these were staged just so we had linux-next
> coverage until you picked them up.
>
> Please pick these up for 4.8 -- the changes are straightforward, are
> required for DM's DAX support, and Dan Williams has also acked them:
>
> https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=6c00531c6affa42b165df73a1eac3289bc45f4c4
> https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=51d1a5abcd0e88cb4528f35643245ea59cf234f1
>
> Feel free to pick them up from patchwork or cherry-pick from
> linux-dm.git
Added for 4.8, thanks!
--
Jens Axboe
^ permalink raw reply
* Re: Cannot start array on disk
From: Bhatia Amit @ 2016-07-21 2:00 UTC (permalink / raw)
To: Phil Turmel, linux-raid@vger.kernel.org
In-Reply-To: <6b958d9f-ec61-3b87-fcd7-ff63c0af32fe@turmel.org>
> I'm not sure if this is supported, by try specifying the version along
> with --examine for each of v0.90, v1.0, v1.1, and v1.2 to see if any
> difference shows. Paste the results from each.
Hi Phil
Only metadata v1.0 seems to be valid for sdc4.
$ sudo mdadm --examine /dev/sdc4 --metadata=0.9
mdadm: No super block found on /dev/sdc4 (Expected magic a92b4efc, got 00000000)
$
$ sudo mdadm --examine /dev/sdc4 --metadata=1.0
/dev/sdc4:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 374e689e:3bfd050c:ab0b0dce:2d50f5fd
Name : MyBookLiveDuo:3
Creation Time : Mon Sep 16 14:53:47 2013
Raid Level : linear
Raid Devices : 2
Avail Dev Size : 5851500528 (2790.21 GiB 2995.97 GB)
Used Dev Size : 0
Super Offset : 5851500528 sectors
State : clean
Device UUID : 9096f74b:0a8f2b61:93347be3:6d3b6c1b
Update Time : Mon Sep 16 14:53:47 2013
Checksum : 77aa5963 - correct
Events : 0
Rounding : 0K
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing)
$
$ sudo mdadm --examine /dev/sdc4 --metadata=1.1
mdadm: No super block found on /dev/sdc4 (Expected magic a92b4efc, got 00000000)
$
$ sudo mdadm --examine /dev/sdc4 --metadata=1.2
mdadm: No super block found on /dev/sdc4 (Expected magic a92b4efc, got 00000000)
$
$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md126 : active raid1 sdc3[2]
500724 blocks super 1.0 [2/1] [_U]
md127 : inactive sdc4[0](S)
2925750264 blocks super 1.0
unused devices: <none>
$
$ sudo mdadm --examine --scan
ARRAY /dev/md/2 metadata=1.0 UUID=7c040c5e:9c30ac6d:e534a129:20457e22 name=MyBookLiveDuo:2
ARRAY /dev/md/3 metadata=1.0 UUID=374e689e:3bfd050c:ab0b0dce:2d50f5fd name=MyBookLiveDuo:3
$
Thanks,
Amit
^ permalink raw reply
* Re: dm stripe: add DAX support
From: Mike Snitzer @ 2016-07-21 0:01 UTC (permalink / raw)
To: axboe-b10kYP2dOMg, axboe-tSWWG44O7X1aa/9Udqfwiw
Cc: linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
In-Reply-To: <1468422189.8908.53.camel-ZPxbGqLxI0U@public.gmane.org>
On Wed, Jul 13 2016 at 11:03am -0400,
Kani, Toshimitsu <toshi.kani-ZPxbGqLxI0U@public.gmane.org> wrote:
> On Tue, 2016-07-12 at 22:01 -0400, Mike Snitzer wrote:
> > On Tue, Jul 12 2016 at 6:22pm -0400,
> > Kani, Toshimitsu <toshi.kani-ZPxbGqLxI0U@public.gmane.org> wrote:
> > > On Fri, 2016-06-24 at 14:29 -0400, Mike Snitzer wrote:
> > > >
> :
> > Thanks for putting this summary together. Unfortunately none of the DM
> > changes can be queued for 4.8 until Jens takes the 2 block core patches:
> > https://patchwork.kernel.org/patch/9196021/
> > https://patchwork.kernel.org/patch/9196019/
> >
> > Not sure what the hold up and/or issue is with them. But I've asked
> > twice (and implicilty a 3rd time here). Hopefully they land in time for
> > 4.8.
>
> Hi Jens,
>
> Can you take the two patches above? These patches add QUEUE_FLAG_DAX and its
> sysfs show func. They allow device-mapper to set dax-capability based on its
> configuration, and also allow user applications to check dax-capability via
> sysfs.
Hi Jens,
As I shared with you before, here are the 2 patches I staged in
linux-next via linux-dm.git's 'for-next' (same as in the patchwork
references above) -- these were staged just so we had linux-next
coverage until you picked them up.
Please pick these up for 4.8 -- the changes are straightforward, are
required for DM's DAX support, and Dan Williams has also acked them:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=6c00531c6affa42b165df73a1eac3289bc45f4c4
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=51d1a5abcd0e88cb4528f35643245ea59cf234f1
Feel free to pick them up from patchwork or cherry-pick from
linux-dm.git
Thanks!
Mike
^ permalink raw reply
* Re: [PATCH v4 18/21] fuse: Add support for pid namespaces
From: Sheng Yang @ 2016-07-20 22:28 UTC (permalink / raw)
To: Seth Forshee
Cc: Eric W. Biederman, Miklos Szeredi, Alexander Viro, Serge Hallyn,
Richard Weinberger, Austin S Hemmelgarn, Miklos Szeredi,
Pavel Tikhomirov, kernel list, linux-bcache, dm-devel, linux-raid,
linux-mtd, linux-fsdevel, fuse-devel, linux-security-module,
selinux, cgroups
In-Reply-To: <20160720125201.GA52079@ubuntu-hedt>
On Wed, Jul 20, 2016 at 5:52 AM, Seth Forshee
<seth.forshee@canonical.com> wrote:
> On Tue, Jul 19, 2016 at 07:44:11PM -0700, Sheng Yang wrote:
>> On Tue, Apr 26, 2016 at 12:36 PM, Seth Forshee
>> <seth.forshee@canonical.com> wrote:
>> > When the userspace process servicing fuse requests is running in
>> > a pid namespace then pids passed via the fuse fd are not being
>> > translated into that process' namespace. Translation is necessary
>> > for the pid to be useful to that process.
>> >
>> > Since no use case currently exists for changing namespaces all
>> > translations can be done relative to the pid namespace in use
>> > when fuse_conn_init() is called. For fuse this translates to
>> > mount time, and for cuse this is when /dev/cuse is opened. IO for
>> > this connection from another namespace will return errors.
>> >
>> > Requests from processes whose pid cannot be translated into the
>> > target namespace are not permitted, except for requests
>> > allocated via fuse_get_req_nofail_nopages. For no-fail requests
>> > in.h.pid will be 0 if the pid translation fails.
>>
>> Hi Seth,
>>
>> This patch caused a regression in our major container use case with
>> FUSE in Ubuntu 16.04, as patch was checked in as Ubuntu Sauce in
>> Ubuntu 4.4.0-6.21 kernel.
>>
>> The use case is:
>> 1. Create a Docker container.
>> 2. Inside the container, start the FUSE backend, and mounted fs.
>> 3. Following step 2 in the container, create a loopback device to map
>> a file in the mounted fuse to create a block device, which will be
>> available to the whole system.
>>
>> It works well before this commit.
>>
>> The use case is broken because no matter which namespace losetup runs,
>> the real request from loopback device seems always come from init ns,
>> thus it will be in different ns running fuse backend. So the request
>> will got denied, because the ns running fuse won't able to see the
>> things from higher level(level 0 in fact) pid namespace.
>>
>> I think since init pid ns has ability to access any process in the
>> system, it should able to access the fuse mounted by any pid namespace
>> process as well.
>>
>> What you think?
>
> It sounds like we need to remove the restriction on accessing the
> filesystem from a different pid namespace. I don't think this poses a
> security problem. However there's no pid mapping that is usable by the
> userspace fuse process, so what do we put in the fuse request? Probably
> the only candidates are 0 and 0xffffffff.
Thanks Seth, I don't think it will be a security problem either, if we
remove the restriction.
>
> So a question for the fuse developers - is one value or the other
> preferrable for fuse_in_header.pid when the pid cannot be mapped, and is
> this going to cause problems for any fuse filesystems? I suspect that
> few filesystems actually look at the pid anyway, and already for a
> filesystem mounted in a pid namespace the values being given to
> userspace won't be correct for the namespace of the fuse process.
>
At least in our system we're not looking into the pid at all.
--Sheng
> Seth
>
^ permalink raw reply
* Re: [PATCH v2] Remove: container should wait for an array to release a drive
From: Jes Sorensen @ 2016-07-20 17:35 UTC (permalink / raw)
To: Tomasz Majchrzak
Cc: linux-raid, aleksey.obitotskiy, pawel.baldysiak,
artur.paszkiewicz
In-Reply-To: <1469001665-13648-1-git-send-email-tomasz.majchrzak@intel.com>
Tomasz Majchrzak <tomasz.majchrzak@intel.com> writes:
> A 'faulty' drive is being removed from a container after it has been
> released by an array, however there is a race there. The drive is
> released asynchronously by a monitor but sometimes it doesn't happen
> before container checks it. It results in a container refusing to remove
> a drive as it still seems to be a part of some array.
>
> It seems 'ping_monitor' could be a solution here to assure monitor has
> had a chance to process the events, however it doesn't resolve the
> problem - sometimes an array has to request a release of the drive few
> times (as the array is busy) and single 'ping_monitor' call is not
> sufficient. As there is no way to query monitor progress, it forces us
> to retry a check several times before an error is returned.
>
> Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
> ---
> Manage.c | 38 +++++++++++++++++++++++++-------------
> 1 file changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/Manage.c b/Manage.c
> index e2e88b8..7f8eb88 100644
> --- a/Manage.c
> +++ b/Manage.c
> @@ -1125,19 +1125,31 @@ int Manage_remove(struct supertype *tst, int fd, struct mddev_dev *dv,
> */
> if (rdev == 0)
> ret = -1;
> - else
> - ret = sysfs_unique_holder(devnm, rdev);
> - if (ret == 0) {
> - pr_err("%s is not a member, cannot remove.\n",
> - dv->devname);
> - close(lfd);
> - return -1;
> - }
> - if (ret >= 2) {
> - pr_err("%s is still in use, cannot remove.\n",
> - dv->devname);
> - close(lfd);
> - return -1;
> + else {
> + /* The drive has already been set to 'faulty', however monitor might
> + * not have had time to process it and the drive might still have
> + * an entry in the 'holders' directory. Try a few times to avoid
> + * a false error */
Sorry for nagging again, but code is 80 characters wide, and comments
should not go beyond the 80 character limit - just like in the
kernel. The preferred format is (with applicable indentation):
/*
* Blah blah blah blah blah
* .... more blah blah blah
*/
Thanks,
Jes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox