* 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 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 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 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.