Changing chunk size
I have determined that a large array was created with an overly-large chunk size. Best way to resize?
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Quoted 2 lines · On Thursday February 15, [email protected] 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
Quoted 5 lines · Neil Brown
Quoted 2 lines · On Thursday February 15, [email protected] wrote:
I have determined that a large array was created with an overly-large chunk size. Best way to resize?
Quoted 8 lines
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.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Quoted 2 lines · Bill Davidsen
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
Signature · 4 lines
______________________________________________________________________ Steve Cousins, Ocean Modeling Group Email: [email protected] Marine Sciences, 452 Aubert Hall http://rocky.umeoce.maine.edu Univ. of Maine, Orono, ME 04469 Phone: (207) 581-4302
Quoted 11 lines · Steve Cousins
Quoted 2 lines · Bill Davidsen
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.
Quoted 10 lines · Justin Piszcz
Quoted 6 lines · Steve Cousins
Quoted 2 lines · Bill Davidsen
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.
Quoted 8 lines
Quoted 5 lines
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.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Quoted 7 lines · Steve Cousins
Quoted 2 lines · Bill Davidsen
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.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Quoted 14 lines · Bill Davidsen
Quoted 5 lines · Neil Brown
Quoted 2 lines · On Thursday February 15, [email protected] wrote:
I have determined that a large array was created with an overly-large chunk size. Best way to resize?
Quoted 8 lines
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.
Quoted 4 lines
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-
Quoted 17 lines · berk walker
Quoted 14 lines · Bill Davidsen
Quoted 13 lines · Neil Brown
Quoted 2 lines · On Thursday February 15, [email protected] 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.
Quoted 5 lines
Quoted 4 lines
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 ;-)
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979