** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Jim Lieb (jim-lieb)
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
@Jim: Thanks for getting back to me on this one!
Your understanding for my purposes is correct. Let me address your
points one by one:
> You save little, if any, power because an array restore requires a
complete disk copy, not an update of some number of out-of-date blocks.
...
No. First of all
@Stephan,
The purpose of RAID is reliability, not a power saving strategy. It is
true that there are bitmaps to minimize the bulk of the re-sync, an
optimization, but that is all it is. The re-sync code schedules these
so that there is minimal impact on overall performance during the re-
sync.
** Summary changed:
- Raid1 HDD and SD card -> bio too big device md0 (248 > 200)
+ Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received t
Mhmhm, I'm replying to myself. Again.
https://kerneltrap.org/mailarchive/linux-kernel/2007/4/10/75875
NeilBrown:
"...
dm doesn't know that md/raid1 has just changed max_sectors and there
is no convenient way for it to find out. So when the filesystem tries
to get the max_sectors for the dm device
@Stephan, As I understand this, you are using an md raid1 to save power
and have a "backup"? This is failure prone and dangerous to your data.
The MD layer is pretty resilient but it is meant for RAID of like disks.
This is why the numbers are weird. It "expects" a scsi/sata hdd and
works best if
This is not a bug in the linux-meta package, moving to the linux
package.
** Package changed: linux-meta (Ubuntu) => linux (Ubuntu)
** Changed in: linux (Ubuntu)
Importance: Undecided => Critical
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.la
** Changed in: linux (Ubuntu)
Status: New => Triaged
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubunt
** Summary changed:
- Raid1 HDD and SD card -> bio too big device md0 (248 > 200)
+ Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received t
Mhmhm, I'm replying to myself. Again.
https://kerneltrap.org/mailarchive/linux-kernel/2007/4/10/75875
NeilBrown:
"...
dm doesn't know that md/raid1 has just changed max_sectors and there
is no convenient way for it to find out. So when the filesystem tries
to get the max_sectors for the dm device
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Jim Lieb (jim-lieb)
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
@Jim: Thanks for getting back to me on this one!
Your understanding for my purposes is correct. Let me address your
points one by one:
> You save little, if any, power because an array restore requires a
complete disk copy, not an update of some number of out-of-date blocks.
...
No. First of all
** Summary changed:
- Raid1 HDD and SD card -> bio too big device md0 (248 > 200)
+ Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received t
Mhmhm, I'm replying to myself. Again.
https://kerneltrap.org/mailarchive/linux-kernel/2007/4/10/75875
NeilBrown:
"...
dm doesn't know that md/raid1 has just changed max_sectors and there
is no convenient way for it to find out. So when the filesystem tries
to get the max_sectors for the dm device
@Stephan, As I understand this, you are using an md raid1 to save power
and have a "backup"? This is failure prone and dangerous to your data.
The MD layer is pretty resilient but it is meant for RAID of like disks.
This is why the numbers are weird. It "expects" a scsi/sata hdd and
works best if
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Jim Lieb (jim-lieb)
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
@Jim: Thanks for getting back to me on this one!
Your understanding for my purposes is correct. Let me address your
points one by one:
> You save little, if any, power because an array restore requires a
complete disk copy, not an update of some number of out-of-date blocks.
...
No. First of all
This is not a bug in the linux-meta package, moving to the linux
package.
** Package changed: linux-meta (Ubuntu) => linux (Ubuntu)
** Changed in: linux (Ubuntu)
Importance: Undecided => Critical
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.la
** Changed in: linux (Ubuntu)
Status: New => Triaged
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubunt
@Stephan,
The purpose of RAID is reliability, not a power saving strategy. It is
true that there are bitmaps to minimize the bulk of the re-sync, an
optimization, but that is all it is. The re-sync code schedules these
so that there is minimal impact on overall performance during the re-
sync.
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Jim Lieb (jim-lieb)
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
@Jim: Thanks for getting back to me on this one!
Your understanding for my purposes is correct. Let me address your
points one by one:
> You save little, if any, power because an array restore requires a
complete disk copy, not an update of some number of out-of-date blocks.
...
No. First of all
@Stephan,
The purpose of RAID is reliability, not a power saving strategy. It is
true that there are bitmaps to minimize the bulk of the re-sync, an
optimization, but that is all it is. The re-sync code schedules these
so that there is minimal impact on overall performance during the re-
sync.
** Summary changed:
- Raid1 HDD and SD card -> bio too big device md0 (248 > 200)
+ Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received t
Mhmhm, I'm replying to myself. Again.
https://kerneltrap.org/mailarchive/linux-kernel/2007/4/10/75875
NeilBrown:
"...
dm doesn't know that md/raid1 has just changed max_sectors and there
is no convenient way for it to find out. So when the filesystem tries
to get the max_sectors for the dm device
@Stephan, As I understand this, you are using an md raid1 to save power
and have a "backup"? This is failure prone and dangerous to your data.
The MD layer is pretty resilient but it is meant for RAID of like disks.
This is why the numbers are weird. It "expects" a scsi/sata hdd and
works best if
This is not a bug in the linux-meta package, moving to the linux
package.
** Package changed: linux-meta (Ubuntu) => linux (Ubuntu)
** Changed in: linux (Ubuntu)
Importance: Undecided => Critical
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.la
** Changed in: linux (Ubuntu)
Status: New => Triaged
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubunt
** Summary changed:
- Raid1 HDD and SD card -> bio too big device md0 (248 > 200)
+ Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received t
Mhmhm, I'm replying to myself. Again.
https://kerneltrap.org/mailarchive/linux-kernel/2007/4/10/75875
NeilBrown:
"...
dm doesn't know that md/raid1 has just changed max_sectors and there
is no convenient way for it to find out. So when the filesystem tries
to get the max_sectors for the dm device
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Jim Lieb (jim-lieb)
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
@Jim: Thanks for getting back to me on this one!
Your understanding for my purposes is correct. Let me address your
points one by one:
> You save little, if any, power because an array restore requires a
complete disk copy, not an update of some number of out-of-date blocks.
...
No. First of all
@Stephan,
The purpose of RAID is reliability, not a power saving strategy. It is
true that there are bitmaps to minimize the bulk of the re-sync, an
optimization, but that is all it is. The re-sync code schedules these
so that there is minimal impact on overall performance during the re-
sync.
@Stephan, As I understand this, you are using an md raid1 to save power
and have a "backup"? This is failure prone and dangerous to your data.
The MD layer is pretty resilient but it is meant for RAID of like disks.
This is why the numbers are weird. It "expects" a scsi/sata hdd and
works best if
This is not a bug in the linux-meta package, moving to the linux
package.
** Package changed: linux-meta (Ubuntu) => linux (Ubuntu)
** Changed in: linux (Ubuntu)
Importance: Undecided => Critical
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.la
** Changed in: linux (Ubuntu)
Status: New => Triaged
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubunt
@Stephan,
The purpose of RAID is reliability, not a power saving strategy. It is
true that there are bitmaps to minimize the bulk of the re-sync, an
optimization, but that is all it is. The re-sync code schedules these
so that there is minimal impact on overall performance during the re-
sync.
@Stephan, As I understand this, you are using an md raid1 to save power
and have a "backup"? This is failure prone and dangerous to your data.
The MD layer is pretty resilient but it is meant for RAID of like disks.
This is why the numbers are weird. It "expects" a scsi/sata hdd and
works best if
This is not a bug in the linux-meta package, moving to the linux
package.
** Package changed: linux-meta (Ubuntu) => linux (Ubuntu)
** Changed in: linux (Ubuntu)
Importance: Undecided => Critical
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.la
** Changed in: linux (Ubuntu)
Status: New => Triaged
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubunt
** Summary changed:
- Raid1 HDD and SD card -> bio too big device md0 (248 > 200)
+ Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received t
Mhmhm, I'm replying to myself. Again.
https://kerneltrap.org/mailarchive/linux-kernel/2007/4/10/75875
NeilBrown:
"...
dm doesn't know that md/raid1 has just changed max_sectors and there
is no convenient way for it to find out. So when the filesystem tries
to get the max_sectors for the dm device
This is not a bug in the linux-meta package, moving to the linux
package.
** Package changed: linux-meta (Ubuntu) => linux (Ubuntu)
** Changed in: linux (Ubuntu)
Importance: Undecided => Critical
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.la
** Changed in: linux (Ubuntu)
Status: New => Triaged
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubunt
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Jim Lieb (jim-lieb)
--
Raid1 HDD and SD card -> data corruption (bio too big device md0 (248 > 200))
https://bugs.launchpad.net/bugs/320638
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
@Jim: Thanks for getting back to me on this one!
Your understanding for my purposes is correct. Let me address your
points one by one:
> You save little, if any, power because an array restore requires a
complete disk copy, not an update of some number of out-of-date blocks.
...
No. First of all
@Stephan,
The purpose of RAID is reliability, not a power saving strategy. It is
true that there are bitmaps to minimize the bulk of the re-sync, an
optimization, but that is all it is. The re-sync code schedules these
so that there is minimal impact on overall performance during the re-
sync.
@Stephan, As I understand this, you are using an md raid1 to save power
and have a "backup"? This is failure prone and dangerous to your data.
The MD layer is pretty resilient but it is meant for RAID of like disks.
This is why the numbers are weird. It "expects" a scsi/sata hdd and
works best if
48 matches
Mail list logo