md software raid
hello
As a newbie to Linux kernel etc.
How do you tell which version of md software raid is included in a specific kernel version?
Is there a command to run which will return this info?
Is it possible to install different versions of md in different kernels?
Your advice is appreciated
Thanks
ian.d
Signature · 2 lines
View this message in context: http://www.nabble.com/md-software-raid-tp26023091p26023091.html Sent from the linux-raid mailing list archive at Nabble.com.
Quoted 10 lines · ian.d
hello
As a newbie to Linux kernel etc.
How do you tell which version of md software raid is included in a specific kernel version?
Is there a command to run which will return this info?
Is it possible to install different versions of md in different kernels?
There's two separate components to Linux software RAID - the md code in the kernel, and the mdadm application which interfaces with it. I very much doubt the kernel code is versioned at all, other than by the kernel version (or GIT version). The mdadm application is versioned, and you can get the installed version by running 'mdadm -V'.
Some of the mdadm functionality will only work with newer kernel versions, but you should be able to run any version with any kernel (within reason anyway) and make use of the core functionality. There may be some exceptions here, but they should be detailed in the release notes for specific versions.
As for changing the md version in the kernel - it may be possible, but generally there's a lot of work involved in back/forward porting code between kernel versions (because of changes to core structures, etc).
Is there any particular reason you're asking this (e.g. needing to use some of the latest functionality with an older kernel)? You may get a more definitive answer if you have a specific case.
HTH,
Robin
Signature · 4 lines
___
( ' } | Robin Hill <[email protected]> |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |Quoted 34 lines
-----Original Message-----
From: [email protected] [mailto:linux-raid- [email protected]] On Behalf Of Robin Hill
Sent: 23 October 2009 10:38
To: [email protected]
Subject: Re: md software raidQuoted 9 lines · ian.d
hello
As a newbie to Linux kernel etc.
How do you tell which version of md software raid is included in a specific kernel version?
Is there a command to run which will return this info? Is it possible to install different versions of md in differentkernels?
Quoted 1 line
There's two separate components to Linux software RAID - the md code in the kernel, and the mdadm application which interfaces with it. I very much doubt the kernel code is versioned at all, other than by the kernel version (or GIT version). The mdadm application is versioned, and you can get the installed version by running 'mdadm -V'.
Some of the mdadm functionality will only work with newer kernel versions, but you should be able to run any version with any kernel (within reason anyway) and make use of the core functionality. There may be some exceptions here, but they should be detailed in the release notes for specific versions.
Quoted 7 lines
As for changing the md version in the kernel - it may be possible, but generally there's a lot of work involved in back/forward porting code between kernel versions (because of changes to core structures, etc).
Is there any particular reason you're asking this (e.g. needing to use some of the latest functionality with an older kernel)? You may get a more definitive answer if you have a specific case.
Thanks this info was very helpful.
The reason I asked was because I have been following a thread re MD-XFS 50% write performance issue with different kernel releases and as performance is important to me I was thinking it might be better for me to use an older kernel (2.6.28.4) but keeping md,mdadm functionality up to date
Ian.d
Quoted 8 lines
HTH,
Robin
--
___
( ' } | Robin Hill <[email protected]> |/ / ) | Little Jim says .... | // !! | "He fallen in de water !!" |
Quoted 43 lines · Ian Docherty
Quoted 34 lines
-----Original Message-----
From: [email protected] [mailto:linux-raid- [email protected]] On Behalf Of Robin Hill
Sent: 23 October 2009 10:38
To: [email protected]
Subject: Re: md software raidQuoted 9 lines · ian.d
hello
As a newbie to Linux kernel etc.
How do you tell which version of md software raid is included in a specific kernel version?
Is there a command to run which will return this info? Is it possible to install different versions of md in differentkernels?
There's two separate components to Linux software RAID - the md code in the kernel, and the mdadm application which interfaces with it. I very much doubt the kernel code is versioned at all, other than by the kernel version (or GIT version). The mdadm application is versioned, and you can get the installed version by running 'mdadm -V'.
Some of the mdadm functionality will only work with newer kernel versions, but you should be able to run any version with any kernel (within reason anyway) and make use of the core functionality. There may be some exceptions here, but they should be detailed in the release notes for specific versions.
Quoted 8 lines
As for changing the md version in the kernel - it may be possible, but generally there's a lot of work involved in back/forward porting code between kernel versions (because of changes to core structures, etc).
Is there any particular reason you're asking this (e.g. needing to use some of the latest functionality with an older kernel)? You may get a more definitive answer if you have a specific case.
Quoted 7 lines
Thanks this info was very helpful.
The reason I asked was because I have been following a thread re MD-XFS 50% write performance issue with different kernel releases and as performance is important to me I was thinking it might be better for me to use an older kernel (2.6.28.4) but keeping md,mdadm functionality up to date
That's certainly a valid point, if you are stuck using xfs by preference or requirement. I have seen claims that 2.6.32 will be better, but I have no intention of testing it, having parted company with xfs a while ago.
Signature · 2 lines
Bill Davidsen <[email protected]> Unintended results are the well-earned reward for incompetence.
Quoted 1 line · Bill Davidsen
That's certainly a valid point, if you are stuck using xfs by preference or requirement. I have seen claims that 2.6.32 will be better, but I have no intention of testing it, having parted company with xfs a while ago.
The OP of the thread metioned, was able to duplicate the slowdown using ext3, so it probably has nothing to do with XFS.
Regards,
Richard
Quoted 9 lines · Richard Scobie
Quoted 3 lines · Bill Davidsen
That's certainly a valid point, if you are stuck using xfs by preference or requirement. I have seen claims that 2.6.32 will be better, but I have no intention of testing it, having parted company with xfs a while ago.
The OP of the thread metioned, was able to duplicate the slowdown using ext3, so it probably has nothing to do with XFS.
It probably has to do with the added writes...if they can try it with ext2 (yeah, yeah, yuck) they might see something.
Especially if this is raid 5 or 6.
cc
Signature · 4 lines
Chris Chen <[email protected]> "The fact that yours is better than anyone else's is not a guarantee that it's any good." -- Seen on a wall
Quoted 4 lines
That's certainly a valid point, if you are stuck using xfs by preference or requirement. I have seen claims that 2.6.32 will be better, but I have no intention of testing it, having parted company with xfs a while ago.
May I ask, "Why?" I am running XFS on both my video server and its
backup. Generally I have been very pleased. The only issue I have had was trying to fsck the arrays. I only have 10G of swap space, and XFS requires much more than that to successfully check file systems in excess of 6T. It wasn't a really big deal, however. I just plugged in a 750G drive, shut down the default swap, and turned it up on the large drive. Once done, I switched the swap back to the boot drive.
Leslie,
How do you check xfs? xfs_check? Why not use xfs_repair -n?
Quoted 18 lines · Leslie Rhorer
Quoted 4 lines
That's certainly a valid point, if you are stuck using xfs by preference or requirement. I have seen claims that 2.6.32 will be better, but I have no intention of testing it, having parted company with xfs a while ago.
May I ask, "Why?" I am running XFS on both my video server and its backup. Generally I have been very pleased. The only issue I have had was trying to fsck the arrays. I only have 10G of swap space, and XFS requires much more than that to successfully check file systems in excess of 6T. It wasn't a really big deal, however. I just plugged in a 750G drive, shut down the default swap, and turned it up on the large drive. Once done, I switched the swap back to the boot drive.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 5 lines
Majed B. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 4 lines
Leslie,
How do you check xfs?
xfs_check?
Yes.
Quoted 1 line
Why not use
xfs_repair-n?
I guess the short answer is, "I didn't know it would make a
difference". I take it, then, xfs_repair uses a completely different method of scanning for errors than xfs_check, one whihcdoes not require so much memory? I find that a bit surprising.
Indeed xfs_repair doesn't require the abusive amount of memory xfs_check requires.
I've been a happy XFS user for a few years now, but the fact the xfsprogs aren't being maintained properly and xfs_check is still a failure, I'm considering other alternatives.
A filesystem that provides speed and a small footprint on the array for its master file table is great, but a filesystem that has maintained tools and tools that work well in case of data corruption is a preferred one, at least to me.
I almost lost 5.5TB worth of data recently and the tools available made it really hard to fix problems.
Quoted 19 lines · Leslie Rhorer
Quoted 4 lines
Leslie,
How do you check xfs?
xfs_check?Yes.
Quoted 1 line
Why not use
xfs_repair-n?I guess the short answer is, "I didn't know it would make a difference". I take it, then,
xfs_repairuses a completely different method of scanning for errors thanxfs_check, one whihcdoes not require so much memory? I find that a bit surprising.--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 5 lines
Majed B. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Majed B.
Indeed
xfs_repairdoesn't require the abusive amount of memoryxfs_checkrequires.I've been a happy XFS user for a few years now, but the fact the xfsprogs aren't being maintained properly and
xfs_checkis still a failure, I'm considering other alternatives.
This should change soon, see the September entry:
http://xfs.org/index.php/XFS_Status_Updates
"On the userspace side a large patch series to reduce the memory usage in xfs_repair to acceptable levels was posted, but not yet merged."
Regards,
Richard
Quoted 10 lines · Richard Scobie
Quoted 6 lines · Majed B.
Indeed
xfs_repairdoesn't require the abusive amount of memoryxfs_checkrequires.I've been a happy XFS user for a few years now, but the fact the xfsprogs aren't being maintained properly and
xfs_checkis still a failure, I'm considering other alternatives.This should change soon, see the September entry:
Quoted 7 lines
http://xfs.org/index.php/XFS_Status_Updates
"On the userspace side a large patch series to reduce the memory usage in
xfs_repairto acceptable levels was posted, but not yet merged."Regards,
Richard
There are several people still actively working on both XFS & its tools and I am sure that they are interested in hearing about issues :-)
ric
Quoted 15 lines · Ric Wheeler
Quoted 14 lines · Richard Scobie
Quoted 6 lines · Majed B.
Indeed
xfs_repairdoesn't require the abusive amount of memoryxfs_checkrequires.I've been a happy XFS user for a few years now, but the fact the xfsprogs aren't being maintained properly and
xfs_checkis still a failure, I'm considering other alternatives.This should change soon, see the September entry:
http://xfs.org/index.php/XFS_Status_Updates
"On the userspace side a large patch series to reduce the memory usage in
xfs_repairto acceptable levels was posted, but not yet merged."
Quoted 8 lines
Quoted 3 lines
Regards,
Richard
There are several people still actively working on both XFS & its tools and I am sure that they are interested in hearing about issues :-)
ric
FWIW, this is merged now, but not yet in a usable release.
Still, existing xfs_repair has much better memory footprint than xfs_check, and it is the tool you want to use whether you are just checking (with -n) or repairing.
xfs_check is more or less deprecated; it is known to have large memory requirements, and xfs_repair is the tool to use.
-Eric
Quoted 2 lines · Eric Sandeen
xfs_checkis more or less deprecated; it is known to have large memory requirements, andxfs_repairis the tool to use.
What about adding a warning message to it then? I guess most people don't check list archives first before using it.
Thanks,
Bernd
Quoted 7 lines · Bernd Schubert
Quoted 2 lines · Eric Sandeen
xfs_checkis more or less deprecated; it is known to have large memory requirements, andxfs_repairis the tool to use.What about adding a warning message to it then? I guess most people don't check list archives first before using it.
IIUC, the plan is to add the one set of checks to xfs_repair that it currently doesn't do (doesn't check free space trees because it simply rebuilds them from scratch during the repair process), then xfs_check will be changed to be wrapper around xfs_repair. i.e. the xfs_check command is most likely not going away, just changing implementation....
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Quoted 8 lines · Richard Scobie
Quoted 6 lines · Majed B.
Indeed
xfs_repairdoesn't require the abusive amount of memoryxfs_checkrequires.I've been a happy XFS user for a few years now, but the fact the xfsprogs aren't being maintained properly and
xfs_checkis still a failure, I'm considering other alternatives.
Quoted 6 lines
This should change soon, see the September entry:
http://xfs.org/index.php/XFS_Status_Updates
"On the userspace side a large patch series to reduce the memory usage in
xfs_repairto acceptable levels was posted, but not yet merged."
I also notice SGI still (since their take-over) seem to feature it fairly prominently on their web site, indicating to me that it probably won't fall into dis-use any time soon...though web sites can be misleading.
Max.
Thank you Richard for the update!
Though with the recent performance drops of XFS on 2.6.3x kernels, and the fact that the XFS patches are fairly new (and probably buggy), I'd rather stay away from XFS for a while and look into other possible options. If any...
Quoted 20 lines · Richard Scobie
Quoted 7 lines · Majed B.
Indeed
xfs_repairdoesn't require the abusive amount of memoryxfs_checkrequires.I've been a happy XFS user for a few years now, but the fact the xfsprogs aren't being maintained properly and
xfs_checkis still a failure, I'm considering other alternatives.This should change soon, see the September entry:
http://xfs.org/index.php/XFS_Status_Updates
"On the userspace side a large patch series to reduce the memory usage in
xfs_repairto acceptable levels was posted, but not yet merged."Regards,
Richard
Signature · 1 line
Majed B.
Quoted 6 lines · Majed B.
Thank you Richard for the update!
Though with the recent performance drops of XFS on 2.6.3x kernels, and the fact that the XFS patches are fairly new (and probably buggy), I'd rather stay away from XFS for a while and look into other possible options. If any...
No, as I mentioned earlier, the original poster of the thread of the "reduced write performance on late kernels", later posted that the slowdown occured on ext filesystems as well and indeed if you search the archive back a week or so, you will find he has bisected the patchs that have caused this regression.
Regards,
Richard
Quoted 6 lines
Thank you Richard for the update!
Though with the recent performance drops of XFS on 2.6.3x kernels, and the fact that the XFS patches are fairly new (and probably buggy), I'd rather stay away from XFS for a while and look into other possible options. If any...
I hear what you are saying, but reformatting an array to a new fs is
definitely a daunting prospect. I have a minor coronary every time I think of deliberately reducing the number of copies of my data from 2 to 1 while the array is re-formatted and the data copied back to the main array. This process takes long enough that the odds of encountering two drive failures on the RAID5 backup system during the copy are not infinitesimal...
<sigh> I guess one of these days I am going to have to bite the bullet and
build a *SECOND* backup system. I don't suppose I will ever breathe perfectly easy until I can have two completely independent systems fail and still not lose any data. That, or maybe Blu-ray disks will become cheap enough to create multi-terabyte backups on them. Right now, the best price I see is $112 a terabyte, and I can do substantially better than that using hard drives. Even if they do get cheaper than hard drives, the thought of swapping out 400+ Blu-Ray discs over a period of several days doesn't really thrill me. Maybe a cold hard drive backup is the answer? It eliminates most of the pitfalls of a Blu-Ray backup, can easily be overwritten, only requires a relative handful of discs, and costs less than $75 a terabyte.
Hmmm...
Leslie,
Backup is never cheap. Unless you print the data in 0 & 1 on paper in font size 8 or 6....or maybe a reduced form of it... heh.
Quoted 22 lines · Leslie Rhorer
I hear what you are saying, but reformatting an array to a new fs is definitely a daunting prospect. I have a minor coronary every time I think of deliberately reducing the number of copies of my data from 2 to 1 while the array is re-formatted and the data copied back to the main array. This process takes long enough that the odds of encountering two drive failures on the RAID5 backup system during the copy are not infinitesimal...
<sigh>
I guess one of these days I am going to have to bite the bullet and build a *SECOND* backup system. I don't suppose I will ever breathe perfectly easy until I can have two completely independent systems fail and still not lose any data. That, or maybe Blu-ray disks will become cheap enough to create multi-terabyte backups on them. Right now, the best price I see is $112 a terabyte, and I can do substantially better than that using hard drives. Even if they do get cheaper than hard drives, the thought of swapping out 400+ Blu-Ray discs over a period of several days doesn't really thrill me. Maybe a cold hard drive backup is the answer? It eliminates most of the pitfalls of a Blu-Ray backup, can easily be overwritten, only requires a relative handful of discs, and costs less than $75 a terabyte.
Quoted 6 lines
Hmmm...
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 4D87015385157D4285D56CA6101072FF3A6675B8@exchange07.valvesoftware.com
Thanks for the numbers Chris! I guess I kind of anticipated that, which is why I suggested using a compressed form, sort of like zip/rar...
Though if the data is mostly multimedia, then I guess it's pointless.
Punch-cards, anyone?
Quoted 4 lines · Chris Green
I'm guessing you could get about a megabyte per sheet of paper this way. So a 1TB drive would take up 1000000 sheets of paper. Looking at staples.com, it looks like that would cost you in the neighborhood of $8000. The ink cartridges would probably cost more, not to mention the cost of a place to store it :-)
Signature · 1 line
Majed B.
} -----Original Message-----
} From: [email protected] [mailto:linux-raid- } [email protected]] On Behalf Of Majed B.
} Sent: Tuesday, October 27, 2009 10:52 PM
} To: Chris Green
} Cc: [email protected]
} Subject: Re: md software raid
}
} Thanks for the numbers Chris! I guess I kind of anticipated that, } which is why I suggested using a compressed form, sort of like } zip/rar...
}
} Though if the data is mostly multimedia, then I guess it's pointless. }
} Punch-cards, anyone?
1 TBytes on punch cards would stack 1,973 miles high. Assuming 100 cards per inch and 80 bytes per card. :)
}
} On Wed, Oct 28, 2009 at 5:45 AM, Chris Green <[email protected]> } wrote:
} > I'm guessing you could get about a megabyte per sheet of paper this way. } > So a 1TB drive would take up 1000000 sheets of paper. Looking at } staples.com,
} > it looks like that would cost you in the neighborhood of $8000. The ink } cartridges
} > would probably cost more, not to mention the cost of a place to store it } :-)
} --
} Majed B.
Quoted 1 line
I'm guessing you could get about a megabyte per sheet of paper this way.
You've got to be kidding! At 72 points/in, a font size of 8 allows
for one byte and one space per inch, or about 10 bytes per line. One can fairly easily display 1KB per page, but nowhere near 1MB.
Quoted 2 lines
So a 1TB drive would take up 1000000 sheets of paper. Looking at staples.com,
Make that more like a billion pages. Remember, the entire Library
of Congress can fit on a 1T drive.
Quoted 2 lines
it looks like that would cost you in the neighborhood of $8000. The ink cartridges
It's more like $8 million.
I was thinking 300dpi on letter paper gives you about 1mbyte, and you'd bloat it by 2x for redundancy, using both sides of the paper. But I guess 300 dpi is actually 300 dots per square inch, not 300 per linear inch, which means its only 10s of k per page.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Leslie Rhorer
Sent: Tuesday, October 27, 2009 8:08 PM
To: [email protected]
Subject: RE: md software raid
Quoted 1 line
I'm guessing you could get about a megabyte per sheet of paper this way.
You've got to be kidding! At 72 points/in, a font size of 8 allows
for one byte and one space per inch, or about 10 bytes per line. One can fairly easily display 1KB per page, but nowhere near 1MB.
Quoted 2 lines
So a 1TB drive would take up 1000000 sheets of paper. Looking at staples.com,
Make that more like a billion pages. Remember, the entire Library
of Congress can fit on a 1T drive.
Quoted 2 lines
it looks like that would cost you in the neighborhood of $8000. The ink cartridges
It's more like $8 million.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines
I was thinking 300dpi on letter paper gives you about 1mbyte, and you'd bloat it by 2x for redundancy, using both sides of the paper. But I guess 300 dpi is actually 300 dots per square inch
No, it's dots per linear inch, or 90,000 dots per square inch,
assuming a square pixel.
Quoted 2 lines
not 300 per
linear inch, which means its only 10s of k per page.
'Not even 10s of K in a human-readable font. I doubt anyone with
normal eyesight could even read the print at 10K per page.
What about microfilm / microfiche?
Quoted 17 lines · Leslie Rhorer
Quoted 3 lines
I was thinking 300dpi on letter paper gives you about 1mbyte, and you'd bloat it by 2x for redundancy, using both sides of the paper. But I guess 300 dpi is actually 300 dots per square inch
No, it's dots per linear inch, or 90,000 dots per square inch,
assuming a square pixel.Quoted 2 lines
not 300 per
linear inch, which means its only 10s of k per page.'Not even 10s of K in a human-readable font. I doubt anyone with
normal eyesight could even read the print at 10K per page.--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
If you just used the 300 dots per inch as 1 bit per dot, you could store 15120000 (300*300*8*10.5) bits per side (assuming 1/4 inch border on 8.5x11 paper 2 sided). That is 1.8MB per page. You would need 555556 pages. That would stack 463 feet high (assuming 100 pages per inch).
} -----Original Message-----
} From: [email protected] [mailto:linux-raid-
} [email protected]] On Behalf Of Chris Green
} Sent: Tuesday, October 27, 2009 11:12 PM
} To: 'Leslie Rhorer'; [email protected]
} Subject: RE: md software raid
}
} I was thinking 300dpi on letter paper gives you about 1mbyte, and you'd } bloat it by 2x for redundancy, using both sides of the paper. } But I guess 300 dpi is actually 300 dots per square inch, not 300 per } linear inch, which means its only 10s of k per page.
}
}
} -----Original Message-----
} From: [email protected] [mailto:linux-raid-
} [email protected]] On Behalf Of Leslie Rhorer
} Sent: Tuesday, October 27, 2009 8:08 PM
} To: [email protected]
} Subject: RE: md software raid
}
} > I'm guessing you could get about a megabyte per sheet of paper this way. }
} You've got to be kidding! At 72 points/in, a font size of 8 allows
} for one byte and one space per inch, or about 10 bytes per line. One can } fairly easily display 1KB per page, but nowhere near 1MB.
}
} > So a 1TB drive would take up 1000000 sheets of paper. Looking at } > staples.com,
}
} Make that more like a billion pages. Remember, the entire Library
} of Congress can fit on a 1T drive.
}
} > it looks like that would cost you in the neighborhood of $8000. The ink } > cartridges
}
} It's more like $8 million.
}
} --
} To unsubscribe from this list: send the line "unsubscribe linux-raid" in } the body of a message to [email protected]
} More majordomo info at http://vger.kernel.org/majordomo-info.html
} --
} To unsubscribe from this list: send the line "unsubscribe linux-raid" in } the body of a message to [email protected]
} More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Guy Watkins
If you just used the 300 dots per inch as 1 bit per dot, you could store 15120000 (300*300*8*10.5) bits per side (assuming 1/4 inch border on 8.5x11 paper 2 sided). That is 1.8MB per page. You would need 555556 pages. That would stack 463 feet high (assuming 100 pages per inch).
Yeah, but who, in their right mind, would stack them all in one pile?
Max
Quoted 41 lines
} -----Original Message-----
} From: [email protected] [mailto:linux-raid-
} [email protected]] On Behalf Of Chris Green
} Sent: Tuesday, October 27, 2009 11:12 PM
} To: 'Leslie Rhorer'; [email protected]
} Subject: RE: md software raid
} } I was thinking 300dpi on letter paper gives you about 1mbyte, and you'd } bloat it by 2x for redundancy, using both sides of the paper.
} But I guess 300 dpi is actually 300 dots per square inch, not 300 per } linear inch, which means its only 10s of k per page.
} } } -----Original Message-----
} From: [email protected] [mailto:linux-raid-
} [email protected]] On Behalf Of Leslie Rhorer
} Sent: Tuesday, October 27, 2009 8:08 PM
} To: [email protected]
} Subject: RE: md software raid
} } > I'm guessing you could get about a megabyte per sheet of paper this way.
} } You've got to be kidding! At 72 points/in, a font size of 8 allows
} for one byte and one space per inch, or about 10 bytes per line. One can } fairly easily display 1KB per page, but nowhere near 1MB.
} } > So a 1TB drive would take up 1000000 sheets of paper. Looking at } > staples.com,
} } Make that more like a billion pages. Remember, the entire Library
} of Congress can fit on a 1T drive.
} } > it looks like that would cost you in the neighborhood of $8000. The ink } > cartridges
} } It's more like $8 million.
} } --
} To unsubscribe from this list: send the line "unsubscribe linux-raid" in } the body of a message to [email protected]
} More majordomo info at http://vger.kernel.org/majordomo-info.html
} --
} To unsubscribe from this list: send the line "unsubscribe linux-raid" in } the body of a message to [email protected]
} More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines
Leslie,
Backup is never cheap.
Yeah, I know, and the most expensive thing in the world is a
non-existent backup. I don't mind os much paying for one backup, but two... well, lets just say I'm part Scott and part German.
Quoted 2 lines
Unless you print the data in 0 & 1 on paper in font size 8 or 6....or maybe a reduced form of it... heh.
Funny you should mention it. A certain military customer of ours
recently ordered a pair of Gig-E circuits (no surprise there), and - believe it or not - four *TELEGRAPH* circuits!
I kid you not.
Quoted 5 lines · Leslie Rhorer
Quoted 4 lines
Leslie,
How do you check xfs?
xfs_check?
Quoted 8 lines
Yes.
Quoted 1 line
Why not use
xfs_repair-n?I guess the short answer is, "I didn't know it would make a
difference". I take it, then,xfs_repairuses a completely different method of scanning for errors thanxfs_check, one whihcdoes not require so much memory? I find that a bit surprising.
xfs_repair is a separate program that is actually mainainted. xfs_check is deprecated and we'll eventually remove it after porting one remaining checking pass over to xfs_repair (currently xfs_repair can't check the freespace btree but only fully rebuild them when in repair mode)
Quoted 5 lines
Quoted 4 lines
Quoted 1 line
Why not use
xfs_repair-n?I guess the short answer is, "I didn't know it would make a
difference". I take it, then,xfs_repairuses a completely differentmethod
Quoted 8 lines
Quoted 2 lines
of scanning for errors than
xfs_check, one whihcdoes not require so much memory? I find that a bit surprising.
xfs_repairis a separate program that is actually mainainted.xfs_checkis deprecated and we'll eventually remove it after porting one remaining checking pass over toxfs_repair(currentlyxfs_repaircan't check the freespace btree but only fully rebuild them when in repair mode)
OK, great! Query: my swap space of 10G was nowhere nearly enough to
cover the useage by xfs_check. Will it be sufficient for xfs_repair with the -n option?