Pascal Hambourg wrote:
> /proc/mdstat
this looks good, however I tried writing to the disk and only one disk led
indicates writes, so I think it is not writing on both disks.
Anyway I will replace those disks
thanks and regards
Le 12/11/2017 à 17:57, deloptes a écrit :
So if you know if in this context I have real RAID - I mean data is written
to both drives?
Sorry, I cannot tell. Insufficient data. You can check in /proc/mdstat.
Thanks Pascal,
Pascal Hambourg wrote:
> Le 10/11/2017 à 09:12, deloptes a écrit :
>>
>>
>> It looks like the new style raid
>
> Indeed, superblock format 1.x. In addition to the "array UUID" which is
> common to all members of the array, it adds a specific "device UUID" for
> each member. blk
Le 10/11/2017 à 17:46, Joe Pfeiffer a écrit :
deloptes writes:
you see in your case PARTUUID is different for both members. In my case it
is identical and this is what is bothering me
It's my understanding that PTUUID on a disk using an MBR corresponds to
the UUID on a disk using a GPT, not
Le 10/11/2017 à 09:12, deloptes a écrit :
Joe Pfeiffer wrote:
Here's what I see when I look at my RAID disks:
/dev/sda2: UUID="67d3c233-96a0-737c-5f88-ed9b936ea3ae"
UUID_SUB="48b56869-6f19-21b9-283f-3eee3ac90cf8" LABEL="snowball:1"
TYPE="linux_raid_member" PARTUUID="3bb3729a-528b-4384-b6a5-b6
David Christensen wrote:
> On 11/10/17 00:12, deloptes wrote:
>> this raid was created ~12y ago without metadata.
>
> https://www.psychologytoday.com/basics/self-harm
>
>
> ;-)
>
> David
appreciated :D - one that respects sarcasm :D
On 11/10/17 00:12, deloptes wrote:
this raid was created ~12y ago without metadata.
https://www.psychologytoday.com/basics/self-harm
;-)
David
Joe Pfeiffer wrote:
> It's my understanding that PTUUID on a disk using an MBR corresponds to
> the UUID on a disk using a GPT, not to PARTUUID (I don't know what on an
> MBR-based disk would correspond to PARTUUID, if anything).
# blkid /dev/sdf1
/dev/sdf1: UUID="5427071b-25c8-fff8-476d-ff8c9852
deloptes writes:
> Hi Joe,
>
> thank you for the mesage
>
> Joe Pfeiffer wrote:
>
>> This is normal. It's the identical UUIDs that tell the system that the
>> partitions go into the same RAID array.
>>
>> Here's what I see when I look at my RAID disks:
>>
>> /dev/sda2: UUID="67d3c233-96a0-737c
Hi Joe,
thank you for the mesage
Joe Pfeiffer wrote:
> This is normal. It's the identical UUIDs that tell the system that the
> partitions go into the same RAID array.
>
> Here's what I see when I look at my RAID disks:
>
> /dev/sda2: UUID="67d3c233-96a0-737c-5f88-ed9b936ea3ae"
> UUID_SUB="48
deloptes writes:
> Hi,
> I noticed recently by accident that when I read/write from the oldest raid
> disks I have - only one of the tray leds blinks. Of course the led could be
> damaged, but rather not, so looking into it I found that both disks in
> question return same UUID. So I am concerned
On 11/09/17 13:04, deloptes wrote:
David Christensen wrote:
What RAID technology are you using?
Linux software raid - kernel is 4.12.10
Most people call it 'mdadm', after the command-line tool. I am running
the same, but on Debian "stable":
2017-11-09 14:00:32 root@dipsy ~
# dpkg-query -
Tobx wrote:
> You can change your partition UUID with fdisk (press x for extra
> functionality). An easy way to create a random UUID is:
>
> $ cat /proc/sys/kernel/random/uuid
>
> If you have the chance to test this, I would give it a try.
Thanks - good idea - I guess I'll first do a backup :)
Thank you for the kind answer. Here are my toughts
David Christensen wrote:
> Answering that question definitively would involve reviewing the source
> code of all the software and firmware on your computer for anything that
> is affected, directly or indirectly, by UUID's or PARTUUID's.
>
>
>
On 11/08/17 23:17, deloptes wrote:
David Christensen wrote:
While trouble-shooting PEBKAS issues is important to me, I have found
that my attempts at trouble-shooting GNU/Linux issues is usually an
exercise in futility. The best I can hope for is finding a way to
reproduce the issue and filing
On 8. Nov 2017, at 22:40, deloptes wrote:
> How is this possible and how to solve it - I would simply add 3rd 500MB disk
> to the raid and remove one of the others, but still what is the impact of
> this (stupid) coincidence …
I would not call it coincidence, what are the odds? There must be a r
David Christensen wrote:
> My file server had a 1.5 TB desktop drive with LUKS and btrfs, created
> with Debian 7. When I rebuilt my SOHO network with Debian 8, all was
> well. But, when I rebuilt my SOHO network with Debian 9, I noted
> weirdness. I don't know if it was Debian, GNU, Linux, LUK
On 11/08/17 13:40, deloptes wrote:
Hi,
I noticed recently by accident that when I read/write from the oldest raid
disks I have - only one of the tray leds blinks. Of course the led could be
damaged, but rather not, so looking into it I found that both disks in
question return same UUID. So I am c
Hi,
I noticed recently by accident that when I read/write from the oldest raid
disks I have - only one of the tray leds blinks. Of course the led could be
damaged, but rather not, so looking into it I found that both disks in
question return same UUID. So I am concerned now that I don't have any tr
19 matches
Mail list logo
