* Changing chunk size
@ 2007-02-15 17:16 Bill Davidsen
2007-02-15 23:24 ` Neil Brown
0 siblings, 1 reply; 9+ messages in thread
From: Bill Davidsen @ 2007-02-15 17:16 UTC (permalink / raw)
To: Linux RAID
I have determined that a large array was created with an overly-large
chunk size. Best way to resize?
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changing chunk size
2007-02-15 17:16 Changing chunk size Bill Davidsen
@ 2007-02-15 23:24 ` Neil Brown
2007-02-16 16:48 ` Bill Davidsen
0 siblings, 1 reply; 9+ messages in thread
From: Neil Brown @ 2007-02-15 23:24 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Linux RAID
On Thursday February 15, davidsen@tmr.com wrote:
> I have determined that a large array was created with an overly-large
> chunk size. Best way to resize?
Dump and restore.
in-place reshapes (such as raid5 + 1 disk => raid6 or
change-chunk-size) are on my list of 'that might be interesting to
implement', but there are plenty of more interesting things. And it
would be very slow. It would need to copy some number of stripes to a
backup somewhere, then copy them back in the new layout, so every
block in the array would be written twice.
NeilBrown
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changing chunk size
2007-02-15 23:24 ` Neil Brown
@ 2007-02-16 16:48 ` Bill Davidsen
2007-02-16 18:49 ` Steve Cousins
2007-02-18 1:51 ` berk walker
0 siblings, 2 replies; 9+ messages in thread
From: Bill Davidsen @ 2007-02-16 16:48 UTC (permalink / raw)
To: Neil Brown; +Cc: Linux RAID
Neil Brown wrote:
> On Thursday February 15, davidsen@tmr.com wrote:
>
>> I have determined that a large array was created with an overly-large
>> chunk size. Best way to resize?
>>
>
> Dump and restore.
>
> in-place reshapes (such as raid5 + 1 disk => raid6 or
> change-chunk-size) are on my list of 'that might be interesting to
> implement', but there are plenty of more interesting things. And it
> would be very slow. It would need to copy some number of stripes to a
> backup somewhere, then copy them back in the new layout, so every
> block in the array would be written twice.
I'm sure "slow" is a relative term, compared to backing up TBs of data
and trying to restore them. Not to mention the lack of inexpensive TB
size backup media. That's totally unavailable at the moment, I'll live
with what I have, thanks.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changing chunk size
2007-02-16 16:48 ` Bill Davidsen
@ 2007-02-16 18:49 ` Steve Cousins
2007-02-16 19:28 ` Justin Piszcz
2007-02-16 23:09 ` Bill Davidsen
2007-02-18 1:51 ` berk walker
1 sibling, 2 replies; 9+ messages in thread
From: Steve Cousins @ 2007-02-16 18:49 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Linux RAID
Bill Davidsen wrote:
>
> I'm sure "slow" is a relative term, compared to backing up TBs of data
> and trying to restore them. Not to mention the lack of inexpensive TB
> size backup media. That's totally unavailable at the moment, I'll live
> with what I have, thanks.
You don't backup your RAID arrays? Yikes! For certain data this would
be fine (data that you can recreate easily) but it sounds like this
isn't the case for you otherwise you'd just wipe the array and recreate
the data. There are other modes of failure than just the drives
themselves (file system corruption for instance) so it is wise to do
backups, even on "redundant" systems.
Good luck,
Steve
--
______________________________________________________________________
Steve Cousins, Ocean Modeling Group Email: cousins@umit.maine.edu
Marine Sciences, 452 Aubert Hall http://rocky.umeoce.maine.edu
Univ. of Maine, Orono, ME 04469 Phone: (207) 581-4302
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changing chunk size
2007-02-16 18:49 ` Steve Cousins
@ 2007-02-16 19:28 ` Justin Piszcz
2007-02-16 23:15 ` Bill Davidsen
2007-02-16 23:09 ` Bill Davidsen
1 sibling, 1 reply; 9+ messages in thread
From: Justin Piszcz @ 2007-02-16 19:28 UTC (permalink / raw)
To: Steve Cousins; +Cc: Bill Davidsen, Linux RAID
On Fri, 16 Feb 2007, Steve Cousins wrote:
>
>
> Bill Davidsen wrote:
>>
>> I'm sure "slow" is a relative term, compared to backing up TBs of data and
>> trying to restore them. Not to mention the lack of inexpensive TB size
>> backup media. That's totally unavailable at the moment, I'll live with what
>> I have, thanks.
>
> You don't backup your RAID arrays? Yikes! For certain data this would be
> fine (data that you can recreate easily) but it sounds like this isn't the
> case for you otherwise you'd just wipe the array and recreate the data. There
> are other modes of failure than just the drives themselves (file system
> corruption for instance) so it is wise to do backups, even on "redundant"
> systems.
>
> Good luck,
>
> Steve
I agree here, RAID is no substitute for backups.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changing chunk size
2007-02-16 18:49 ` Steve Cousins
2007-02-16 19:28 ` Justin Piszcz
@ 2007-02-16 23:09 ` Bill Davidsen
1 sibling, 0 replies; 9+ messages in thread
From: Bill Davidsen @ 2007-02-16 23:09 UTC (permalink / raw)
To: Steve Cousins; +Cc: Linux RAID
Steve Cousins wrote:
>
>
> Bill Davidsen wrote:
>>
>> I'm sure "slow" is a relative term, compared to backing up TBs of
>> data and trying to restore them. Not to mention the lack of
>> inexpensive TB size backup media. That's totally unavailable at the
>> moment, I'll live with what I have, thanks.
>
> You don't backup your RAID arrays? Yikes! For certain data this would
> be fine (data that you can recreate easily) but it sounds like this
> isn't the case for you otherwise you'd just wipe the array and
> recreate the data. There are other modes of failure than just the
> drives themselves (file system corruption for instance) so it is wise
> to do backups, even on "redundant" systems.
My personal and business system are backed up. On "projects" those who
write the budget set the policy and I just make sure I have a risk
assessment with their acceptance in writing. University is not like real
life in many cases.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changing chunk size
2007-02-16 19:28 ` Justin Piszcz
@ 2007-02-16 23:15 ` Bill Davidsen
0 siblings, 0 replies; 9+ messages in thread
From: Bill Davidsen @ 2007-02-16 23:15 UTC (permalink / raw)
To: Justin Piszcz; +Cc: Steve Cousins, Linux RAID
Justin Piszcz wrote:
>
>
> On Fri, 16 Feb 2007, Steve Cousins wrote:
>
>>
>>
>> Bill Davidsen wrote:
>>>
>>> I'm sure "slow" is a relative term, compared to backing up TBs of
>>> data and trying to restore them. Not to mention the lack of
>>> inexpensive TB size backup media. That's totally unavailable at the
>>> moment, I'll live with what I have, thanks.
>>
>> You don't backup your RAID arrays? Yikes! For certain data this
>> would be fine (data that you can recreate easily) but it sounds like
>> this isn't the case for you otherwise you'd just wipe the array and
>> recreate the data. There are other modes of failure than just the
>> drives themselves (file system corruption for instance) so it is wise
>> to do backups, even on "redundant" systems.
>>
>> Good luck,
>>
>> Steve
>
> I agree here, RAID is no substitute for backups.
>
Neither is a 2nd copy on another machine, if it isn't something you can
store off site, it's not a backup. One of the few things I liked about
working for {a major telco} was that they had a "smoking hole" recovery
policy, what do you do when the data center is a smoking hole. I don't
get that kind of budget in other places.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changing chunk size
2007-02-16 16:48 ` Bill Davidsen
2007-02-16 18:49 ` Steve Cousins
@ 2007-02-18 1:51 ` berk walker
2007-02-18 20:17 ` Bill Davidsen
1 sibling, 1 reply; 9+ messages in thread
From: berk walker @ 2007-02-18 1:51 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Neil Brown, Linux RAID
Bill Davidsen wrote:
> Neil Brown wrote:
>> On Thursday February 15, davidsen@tmr.com wrote:
>>
>>> I have determined that a large array was created with an
>>> overly-large chunk size. Best way to resize?
>>>
>>
>> Dump and restore.
>>
>> in-place reshapes (such as raid5 + 1 disk => raid6 or
>> change-chunk-size) are on my list of 'that might be interesting to
>> implement', but there are plenty of more interesting things. And it
>> would be very slow. It would need to copy some number of stripes to a
>> backup somewhere, then copy them back in the new layout, so every
>> block in the array would be written twice.
> I'm sure "slow" is a relative term, compared to backing up TBs of data
> and trying to restore them. Not to mention the lack of inexpensive TB
> size backup media. That's totally unavailable at the moment, I'll live
> with what I have, thanks.
> If you were to be a gambler, Bill - Get 2 disks big enough to store
> your data, create a RAID5 mising one, and copy over the data. Re do
> the original array, and copy back.
Yeah, $0.02 doesn't buy much anymore. Besides, you'll be needing bigger
disks for the next machine you build,eh?
b-
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Changing chunk size
2007-02-18 1:51 ` berk walker
@ 2007-02-18 20:17 ` Bill Davidsen
0 siblings, 0 replies; 9+ messages in thread
From: Bill Davidsen @ 2007-02-18 20:17 UTC (permalink / raw)
To: berk walker; +Cc: Neil Brown, Linux RAID
berk walker wrote:
>
>
> Bill Davidsen wrote:
>> Neil Brown wrote:
>>> On Thursday February 15, davidsen@tmr.com wrote:
>>>
>>>> I have determined that a large array was created with an
>>>> overly-large chunk size. Best way to resize?
>>>>
>>>
>>> Dump and restore.
>>>
>>> in-place reshapes (such as raid5 + 1 disk => raid6 or
>>> change-chunk-size) are on my list of 'that might be interesting to
>>> implement', but there are plenty of more interesting things. And it
>>> would be very slow. It would need to copy some number of stripes to a
>>> backup somewhere, then copy them back in the new layout, so every
>>> block in the array would be written twice.
>> I'm sure "slow" is a relative term, compared to backing up TBs of
>> data and trying to restore them. Not to mention the lack of
>> inexpensive TB size backup media. That's totally unavailable at the
>> moment, I'll live with what I have, thanks.
>
>
>> If you were to be a gambler, Bill - Get 2 disks big enough to store
>> your data, create a RAID5 mising one, and copy over the data. Re do
>> the original array, and copy back.
> Yeah, $0.02 doesn't buy much anymore. Besides, you'll be needing
> bigger disks for the next machine you build,eh?
Not unless the project leader say so. He can send me a note on a capital
expenses approval form ;-)
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2007-02-18 20:17 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-15 17:16 Changing chunk size Bill Davidsen
2007-02-15 23:24 ` Neil Brown
2007-02-16 16:48 ` Bill Davidsen
2007-02-16 18:49 ` Steve Cousins
2007-02-16 19:28 ` Justin Piszcz
2007-02-16 23:15 ` Bill Davidsen
2007-02-16 23:09 ` Bill Davidsen
2007-02-18 1:51 ` berk walker
2007-02-18 20:17 ` Bill Davidsen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.