On Sun, 25 Jun 2006, Bill Davidsen wrote:
Justin Piszcz wrote:
On Sat, 24 Jun 2006, Neil Brown wrote:
On Friday June 23, [EMAIL PROTECTED] wrote:
The problem is that there is no cost effective backup available.
One-liner questions :
- How does Google make backups ?
No, Google ARE
Adam Talbot wrote:
Not exactly sure how to tune for stripe size.
What would you advise?
-Adam
See the -R option of mke2fs. I don't have a number for the performance
impact of this, but I bet someone else on the list will. Depending on
what posts you read, reports range from measurable
On Sat, 24 Jun 2006 at 3:52pm, Adam Talbot wrote
nas tmp # time tar cf - . | (cd /data ; tar xf - )
A (bit) cleaner way to accomplish the same thing:
tar cf - --totals . | tar xC /data -f -
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
-
To unsubscribe from
ACK!
At one point some one stated that they were having problems with XFS
crashing under high NFS loads... Did it look something like this?
-Adam
Starting XFS recovery on filesystem: md0 (logdev: internal)
Filesystem md0: XFS internal error xlog_valid_rec_header(1) at line
3478 of file
On 6/23/06, Nix [EMAIL PROTECTED] wrote:
On 23 Jun 2006, PFC suggested tentatively:
- ext3 is slow if you have many files in one directory, but has
more mature tools (resize, recovery etc)
This is much less true if you turn on the dir_index feature.
However, even with dir_index,
Adam Talbot wrote:
ACK!
At one point some one stated that they were having problems with XFS
crashing under high NFS loads... Did it look something like this?
-Adam
nope, it looked like the trace below - and I could make it happen
consistently by thrashing xfs.
Not even sure it was
winspeareAdam Talbot wrote:
OK, this topic I relay need to get in on.
I have spent the last few week bench marking my new 1.2TB, 6 disk, RAID6
array. I wanted real numbers, not This FS is faster because... I have
moved over 100TB of data on my new array running the bench mark
testing. I have
Justin Piszcz wrote:
On Sat, 24 Jun 2006, Neil Brown wrote:
On Friday June 23, [EMAIL PROTECTED] wrote:
The problem is that there is no cost effective backup available.
One-liner questions :
- How does Google make backups ?
No, Google ARE the backups :-)
- Aren't tapes dead yet ?
Not exactly sure how to tune for stripe size.
What would you advise?
-Adam
Bill Davidsen wrote:
winspeareAdam Talbot wrote:
OK, this topic I relay need to get in on.
I have spent the last few week bench marking my new 1.2TB, 6 disk, RAID6
array. I wanted real numbers, not This FS is faster
OK, this topic I relay need to get in on.
I have spent the last few week bench marking my new 1.2TB, 6 disk, RAID6
array. I wanted real numbers, not This FS is faster because... I have
moved over 100TB of data on my new array running the bench mark
testing. I have yet to have any major problems
Adam Talbot wrote:
OK, this topic I relay need to get in on.
I have spent the last few week bench marking my new 1.2TB, 6 disk, RAID6
array.
Very interesting. Thanks.
Did you get around to any 'tuning'.
Things like raid chunk size, external logs for xfs, blockdev readahead
on the underlying
- XFS is faster and fragments less, but make sure you have a good UPS
- ReiserFS 3.6 is mature and fast, too, you might consider it
- ext3 is slow if you have many files in one directory, but has more
mature tools (resize, recovery etc)
I'd go with XFS or Reiser.
2006/6/23, PFC [EMAIL PROTECTED]:
- XFS is faster and fragments less, but make sure you have a good UPS
Why a good UPS ? XFS has a good strong journal, I never had an issue
with it yet... And believe me, I did have some dirty things happening
here...
- ReiserFS 3.6 is mature
On Fri, 23 Jun 2006, Chris Allen wrote:
Strange that whatever the filesystem you get equal numbers of people
saying that
they have never lost a single byte to those who have had horrible
corruption and
would never touch it again. We stopped using XFS about a year ago because we
were getting
Strange that whatever the filesystem you get equal numbers of people
saying that
they have never lost a single byte to those who have had horrible
corruption and
would never touch it again.
[...]
Loosing data is worse than loosing anything else. You can buy you
another hard drive, you can buy
Chris Allen wrote:
Francois Barre wrote:
2006/6/23, PFC [EMAIL PROTECTED]:
- XFS is faster and fragments less, but make sure you have a
good UPS
Why a good UPS ? XFS has a good strong journal, I never had an issue
with it yet... And believe me, I did have some dirty things
2006/6/23, Francois Barre [EMAIL PROTECTED]:
Loosing data is worse than loosing anything else. You can buy you
That's why RAID is no excuse for backups.
Best
Martin
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More
That's why RAID is no excuse for backups.
Of course yes, but...
(I'm working in car industry) Raid is your active (if not pro-active)
security system, like a car ESP ; if something goes wrong, it
gracefully and automagically re-align to the *safe way*. Whereas
backup is your airbag. It's always
Martin Schröder wrote:
2006/6/23, Francois Barre [EMAIL PROTECTED]:
Loosing data is worse than loosing anything else. You can buy you
That's why RAID is no excuse for backups.
We have 50TB stored data now and maybe 250TB this time next year.
We mirror the most recent 20TB to a secondary
Martin Schröder wrote:
2006/6/23, Francois Barre [EMAIL PROTECTED]:
Loosing data is worse than loosing anything else. You can buy you
That's why RAID is no excuse for backups.
The problem is that there is no cost effective backup available. When a
tape was the same size as a disk and
The problem is that there is no cost effective backup available.
One-liner questions :
- How does Google make backups ?
- Aren't tapes dead yet ?
- What about a NUMA principle applied to storage ?
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to
On Jun 23, 2006 17:01 +0300, Al Boldi wrote:
Chris Allen wrote:
Francois Barre wrote:
2006/6/23, PFC [EMAIL PROTECTED]:
- ext3 is slow if you have many files in one directory, but
has more mature tools (resize, recovery etc)
Please use mke2fs -O dir_index or tune2fs -O
Al Boldi wrote:
Chris Allen wrote:
Francois Barre wrote:
2006/6/23, PFC [EMAIL PROTECTED]:
- XFS is faster and fragments less, but make sure you have a
good UPS
Why a good UPS ? XFS has a good strong journal, I never had an issue
with it yet... And believe me,
Andreas Dilger wrote:
On Jun 23, 2006 17:01 +0300, Al Boldi wrote:
Chris Allen wrote:
Francois Barre wrote:
2006/6/23, PFC [EMAIL PROTECTED]:
- ext3 is slow if you have many files in one directory, but
has more mature tools (resize, recovery etc)
Christian Pedaschus wrote:
for ext3 use (on unmounted disks):
tune2fs -O has_journal -o journal_data /dev/{disk}
tune2fs -O dir_index /dev/{disk}
if data is on the drive, you need to run a fsck afterwards and it uses a
good bit of ram, but it makes ext3 a good bit faster.
and my main points
On Fri, Jun 23, 2006 at 11:21:34AM -0500, Russell Cattelan wrote:
When you refer to data=ordered are you taking about ext3 user data
journaling?
iirc, data=ordered just writes new data out before updating block pointers,
the file's length in its inode, and the block usage bitmap. That way you
On 23 Jun 2006, Francois Barre uttered the following:
The problem is that there is no cost effective backup available.
One-liner questions :
- How does Google make backups ?
Replication across huge numbers of cheap machines on a massively
distributed filesystem.
--
`NB: Anyone suggesting
On 23 Jun 2006, PFC suggested tentatively:
- ext3 is slow if you have many files in one directory, but has
more mature tools (resize, recovery etc)
This is much less true if you turn on the dir_index feature.
--
`NB: Anyone suggesting that we should say Tibibytes instead of
On 23 Jun 2006, Christian Pedaschus said:
and my main points for using ext3 is still: it's a very mature fs,
nobody will tell you such horrible storys about data-lossage with ext3
than with any other filesystem.
Actually I can, but it required bad RAM *and* a broken disk controller
*and* an
On Friday June 23, [EMAIL PROTECTED] wrote:
The problem is that there is no cost effective backup available.
One-liner questions :
- How does Google make backups ?
No, Google ARE the backups :-)
- Aren't tapes dead yet ?
LTO-3 does 300Gig, and LTO-4 is planned.
They may not cope with
Dear All,
I have a Linux storage server containing 16x750GB drives - so 12TB raw
space.
If I make them into a single RAID5 array, then it appears my only
choice for a filesystem is XFS - as EXT3 won't really handle partitions
over 8TB.
Alternatively, I could split each drive into 2
On Thu, 22 Jun 2006, Chris Allen wrote:
Dear All,
I have a Linux storage server containing 16x750GB drives - so 12TB raw
space.
Just one thing - Do you want to use RAID-5 or RAID-6 ?
I just ask, as with that many drives (and that much data!) the
possibilities of a 2nd drive failure is
H. Peter Anvin wrote:
Gordon Henderson wrote:
On Thu, 22 Jun 2006, Chris Allen wrote:
Dear All,
I have a Linux storage server containing 16x750GB drives - so 12TB raw
space.
Just one thing - Do you want to use RAID-5 or RAID-6 ?
I just ask, as with that many drives (and that much data!)
33 matches
Mail list logo
