Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #605 > unrolled thread

linux raid vs hw raid

Back to article view | Back to comp.os.linux.misc

Contents

  linux raid vs hw raid Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2011-04-05 19:39 -0700
    Re: linux raid vs hw raid Tim Watts <tw@dionic.net> - 2011-04-06 08:01 +0100
      Re: linux raid vs hw raid David Brown <david@westcontrol.removethisbit.com> - 2011-04-06 10:03 +0200
        Re: linux raid vs hw raid Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2011-04-06 14:00 -0700
          Re: linux raid vs hw raid David Brown <david.brown@removethis.hesbynett.no> - 2011-04-06 23:42 +0200
          Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-08 10:45 +1000
            Re: linux raid vs hw raid David Brown <david@westcontrol.removethisbit.com> - 2011-04-08 11:12 +0200
              Re: linux raid vs hw raid Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2011-04-08 08:22 -0700
                Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-09 09:51 +1000
                  Re: linux raid vs hw raid Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2011-04-08 17:10 -0700
                    Re: linux raid vs hw raid David Brown <david.brown@removethis.hesbynett.no> - 2011-04-09 13:14 +0200
              Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-09 09:47 +1000
                Re: linux raid vs hw raid David Brown <david.brown@removethis.hesbynett.no> - 2011-04-09 13:55 +0200
            Re: linux raid vs hw raid Tris Orendorff <triso@remove-me.cogeco.ca> - 2011-04-12 18:04 +0000
              Re: linux raid vs hw raid Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2011-04-12 11:34 -0700
                Re: linux raid vs hw raid The Natural Philosopher <tnp@invalid.invalid> - 2011-04-12 21:13 +0100
                  Re: linux raid vs hw raid David Brown <david@westcontrol.removethisbit.com> - 2011-04-13 09:45 +0200
                    Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-14 13:42 +1000
                      Re: linux raid vs hw raid David Brown <david@westcontrol.removethisbit.com> - 2011-04-14 09:15 +0200
                        Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-15 08:03 +1000
                          Re: linux raid vs hw raid Tim Watts <tw@dionic.net> - 2011-04-15 07:22 +0100
                          Re: linux raid vs hw raid David Brown <david@westcontrol.removethisbit.com> - 2011-04-15 09:28 +0200
                            Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-19 11:20 +1000
                Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-14 13:38 +1000
                  Re: linux raid vs hw raid Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2011-04-13 21:49 -0700
              Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-14 13:34 +1000
                Re: linux raid vs hw raid Tris Orendorff <triso@remove-me.cogeco.ca> - 2011-04-15 21:59 +0000
                  Re: linux raid vs hw raid "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-04-16 00:56 +0200
                    Re: linux raid vs hw raid The Natural Philosopher <tnp@invalid.invalid> - 2011-04-16 01:32 +0100
    Re: linux raid vs hw raid Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2011-04-08 21:38 +0300
      Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-09 09:53 +1000
    Re: linux raid vs hw raid KR <kristian.rasmussen@broadpark.no.spam.com> - 2011-04-09 11:56 +0200
      Re: linux raid vs hw raid Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2011-04-09 10:32 -0700
        Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-10 11:12 +1000
          Re: linux raid vs hw raid Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2011-04-09 18:59 -0700
            Re: linux raid vs hw raid KR <kristian.rasmussen@broadpark.no.spam.com> - 2011-04-10 04:32 +0200
              Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-10 12:46 +1000
                Re: linux raid vs hw raid Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2011-04-09 20:39 -0700
      Re: linux raid vs hw raid Robert Riches <spamtrap42@jacob21819.net> - 2011-04-10 03:47 +0000
        Re: linux raid vs hw raid Balwinder S Dheeman <bsd.SANSPAM@anu.homelinux.net> - 2011-04-10 11:11 +0530
          Re: linux raid vs hw raid Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2011-04-09 23:29 -0700
            Re: linux raid vs hw raid Balwinder S Dheeman <bsd.SANSPAM@anu.homelinux.net> - 2011-04-10 14:05 +0530
          Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-10 20:16 +1000
            Re: linux raid vs hw raid Tim Watts <tw@dionic.net> - 2011-04-10 11:28 +0100
            Re: linux raid vs hw raid Balwinder S Dheeman <bsd.SANSPAM@anu.homelinux.net> - 2011-04-10 19:43 +0530
          Re: linux raid vs hw raid Robert Riches <spamtrap42@jacob21819.net> - 2011-04-12 03:44 +0000
            Re: linux raid vs hw raid Balwinder S Dheeman <bsd.SANSPAM@anu.homelinux.net> - 2011-04-12 13:56 +0530
        Re: linux raid vs hw raid Grant <omg@grrr.id.au> - 2011-04-10 20:09 +1000
          Re: linux raid vs hw raid Robert Riches <spamtrap42@jacob21819.net> - 2011-04-12 03:37 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#747

Grant wrote:

> On Thu, 14 Apr 2011 09:15:32 +0200, David Brown

> Don't leave a saturated /tmp space!
>>
>>(Note that /var/tmp should really survive a reboot.  However, I have
>>never heard of any programs that actually rely on that - but no
>>guarantees.  /tmp should always be safe on tmpfs.)
> 
> Hmm, I don't do anything special for /var/tmp, but on a slack-11.0 box
> been up 16 days, it's empty.  ON the 'pooh' box above, it's got old crap
> surviving boot for KDE, 2.2MB for a single user, wonder why?  I tend
> towards wanting to flush that one on boot too, or make it in tmpfs.

What I do is cron a find ... | xargs rm that kills off anything with an 
atime *and* mtime more than a few days old. It would work well enough for 
mtime alone if you have "notime" on.

Cheers

Tim



-- 
Tim Watts

[toc] | [prev] | [next] | [standalone]

#748

On 15/04/2011 00:03, Grant wrote:
> On Thu, 14 Apr 2011 09:15:32 +0200, David Brown<david@westcontrol.removethisbit.com>  wrote:
>
>> On 14/04/2011 05:42, Grant wrote:
>>> On Wed, 13 Apr 2011 09:45:58 +0200, David Brown<david@westcontrol.removethisbit.com>   wrote:
>>>
>>>> On 12/04/2011 22:13, The Natural Philosopher wrote:
>>>>> Keith Keller wrote:
>>>>>> The
>>>>>> kernel will move things to swap if it hasn't been used in a while and
>>>>>> free memory is wanted; when the memory frees up, it can leave that data
>>>>>> in swap so that it can use more physical memory for other tasks (e.g.,
>>>>>> more disk buffers).
>>>>>
>>>>> That is key, It means the rarely used admin processes that ar
>>>>> essentially asleep, do not fill the RAM.
>>>>
>>>> Such processes are usually small, but it's a good principle none the less.
>>>>
>>>>
>>>> The reason I like swap space is as a backing store for tmpfs
>>>> filesystems.  I usually put /tmp and /var/tmp on tmpfs, and sometimes
>>>> have additional tmpfs mounts for odd purposes (such as the build
>>>> directories for large compilations - though obviously that's more
>>>> desktop than server usage).  Tmpfs is much faster and more efficient
>>>> than any other filesystem, even if the data is stored on a disk rather
>>>> than in memory, because it does not give the slightest care to data
>>>> reliability.
>>>
>>> Wonder if you could show your relevant /etc/fstab lines?  I'm curious
>>> how other do this?
>>
>> Putting /tmp on tmpfs is not rocket science - if you thought I had some
>> cunning secret here, I have to disappoint you :
>>
>> tmpfs /tmp tmpfs defaults 0 0
>> tmpfs /var/tmp tmpfs defaults 0 0
>
> So from where did I get this?
> ...
> tmpfs           /dev/shm        tmpfs           defaults                0 0
> #
> # run /tmp in memory, use up to twice physical memory size, 8GB!
> none    /tmp    tmpfs           size=8096M,mode=1777,nodev,nosuid       0 0
> #
>

That will work fine too.  (It doesn't really matter if you have "tmpfs" 
or "none" first, since there is no underlying device.)  You've got 
options there to change the maximum size of the tmpfs and to add a touch 
stronger security.


> It works too, in that dd'ing to a new file in /tmp will use half memory
> then expand into swap space:
>
> root@pooh:~# time (dd if=/dev/zero bs=1G count=6 of=/tmp/zeroes; sync)
> 6+0 records in
> 6+0 records out
> 6442450944 bytes (6.4 GB) copied, 25.6495 s, 251 MB/s
>
> real    0m27.977s
> user    0m0.003s
> sys     0m9.449s
>
> Why this confusion with GiB and GB?  dd counts by GiB, reports in decimal
> GB, a bet each way?  And yes, running into swap space takes a lot of time ;)
> Swap is on RAID10, now set  to o2 :)

Running into swap takes a lot more time than keeping everything in 
memory.  But the key comparison is to do the same dd directly to a file 
system, and look at the difference.

>
> root@pooh:~# ls -l /tmp/
> total 6303772
> -rw-r--r-- 1 root root 6442450944 2011-04-15 07:40 zeroes
>
> root@pooh:~# cat /proc/swaps
> Filename                                Type            Size    Used    Priority
> /dev/md127                              partition       8386300 4815424 -1
>
> root@pooh:~# free
>               total       used       free     shared    buffers     cached
> Mem:       4053296    2269572    1783724          0      47532    1754452
> -/+ buffers/cache:     467588    3585708
> Swap:      8386300    4815332    3570968
>
> root@pooh:~# time (dd if=/dev/zero bs=1G count=6 of=/tmp/zeroes2; sync)
> dd: writing `/tmp/zeroes2': No space left on device
> 2+0 records in
> 1+0 records out
> 2030231552 bytes (2.0 GB) copied, 6.60451 s, 307 MB/s
>
> real    0m8.519s
> user    0m0.000s
> sys     0m4.110s
>
> root@pooh:~# ls -l /tmp/
> total 8290308
> -rw-r--r-- 1 root root 6442450944 2011-04-15 07:40 zeroes
> -rw-r--r-- 1 root root 2030231552 2011-04-15 07:50 zeroes2
>
> Shouldn't I get 10GB into /tmp if it has 2GB of real memory plus the 8GB
> swap sapce?  No, because I set /tmp size, had to, to make it go larger
> than tmpfs default.
>

Correct.

You can always resize a tmpfs with something like  "mount -o 
remount,size=12G /tmp".


mvh.,

David


> root@pooh:~# rm /tmp/z*
>
> Don't leave a saturated /tmp space!
>>
>> (Note that /var/tmp should really survive a reboot.  However, I have
>> never heard of any programs that actually rely on that - but no
>> guarantees.  /tmp should always be safe on tmpfs.)
>
> Hmm, I don't do anything special for /var/tmp, but on a slack-11.0 box
> been up 16 days, it's empty.  ON the 'pooh' box above, it's got old crap
> surviving boot for KDE, 2.2MB for a single user, wonder why?  I tend
> towards wanting to flush that one on boot too, or make it in tmpfs.
>
> root@pooh:~# ls -las /var/tmp
> total 1
> 0 drwxrwxrwt  3 root  root   80 2011-01-07 11:10 ./
> 1 drwxr-xr-x 19 root  root  536 2011-02-10 08:03 ../
> 0 drwx------  3 grant wheel 128 2011-01-07 11:12 kdecache-grant/
> root@pooh:~# ls -las /var/tmp/kdecache-grant/
> total 2166
>     0 drwx------ 3 grant wheel     128 2011-01-07 11:12 ./
>     0 drwxrwxrwt 3 root  root       80 2011-01-07 11:10 ../
>     0 drwx------ 2 grant wheel     168 2011-01-07 11:13 kpc/
> 2162 -rw-r--r-- 1 grant wheel 2211743 2011-01-07 11:12 ksycoca4
>     4 -rw-r--r-- 1 grant wheel     358 2011-01-07 11:12 ksycoca4stamp
> root@pooh:~# du -sh /var/tmp
> 2.2M    /var/tmp
>>
>> You can make a new tmpfs on another directory:
>>
>> mkdir t
>> mount -t tmpfs tmpfs t
>>
>> By default, tmpfs mounts are limited in size to half your physical ram -
>> but you can change that with the "size" mount option.  tmpfs takes
>> negligible space overhead - you only use ram/swap for the files stored
>> there.
>
> Thanks.
>
> Grant.

[toc] | [prev] | [next] | [standalone]

#792

On Fri, 15 Apr 2011 09:28:57 +0200, David Brown <david@westcontrol.removethisbit.com> wrote:

>On 15/04/2011 00:03, Grant wrote:
...
>> Shouldn't I get 10GB into /tmp if it has 2GB of real memory plus the 8GB
>> swap sapce?  No, because I set /tmp size, had to, to make it go larger
>> than tmpfs default.
>>
>
>Correct.
>
>You can always resize a tmpfs with something like  "mount -o 
>remount,size=12G /tmp".

I'm getting all these hints for 'keeper' posts, thank you.  Maybe I'll 
collect them onto a web page for reference.

Grant.

[toc] | [prev] | [next] | [standalone]

#710

On Tue, 12 Apr 2011 11:34:39 -0700, Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:

>On 2011-04-12, Tris Orendorff <triso@remove-me.cogeco.ca> wrote:
>>
>>  Swap space?  Isn't that useless for a server?  We've found it next-to-useless on our desktops even with the fastest SSDs.
>
>It's not *useless* per se.  The example I sometimes see cited (even in
>this thread?) is with xfs repairs on large filesystems.  These can take
>a ton of memory, but much of it isn't active, and let's face it, you
>probably really really want the xfs check or repair to work no matter
>what, so you'd be willing to sacrifice performance for results.  (Of
>course you need plenty of free disk space on an unaffected fs!)

Any rough value for that?  I've just started using XFS on a box with a 
couple RAIDs.  I tend to like FS size stay below 70 or 80% based vaguely 
on what I've picked up over the years.  

Grant.

[toc] | [prev] | [next] | [standalone]

#713

On 2011-04-14, Grant <omg@grrr.id.au> wrote:
> On Tue, 12 Apr 2011 11:34:39 -0700, Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
>>
>>It's not *useless* per se.  The example I sometimes see cited (even in
>>this thread?) is with xfs repairs on large filesystems.  These can take
>>a ton of memory, but much of it isn't active, and let's face it, you
>>probably really really want the xfs check or repair to work no matter
>>what, so you'd be willing to sacrifice performance for results.  (Of
>>course you need plenty of free disk space on an unaffected fs!)
>
> Any rough value for that?  I've just started using XFS on a box with a 
> couple RAIDs.  I tend to like FS size stay below 70 or 80% based vaguely 
> on what I've picked up over the years.  

Errr...I don't know for sure.  Here's a recent thread you might consider
using as a rough guide:

http://old.nabble.com/Question-regarding-xfs_repair---memory-requirement.-td30497281.html

I know I had no problems running xfs_repair on a ~3TB XFS filesystem,
but that machine has 4GB of physical memory, so I wouldn't even come
close to the limits quoted on that page.  Between the above, though,
plus all the other docs I've read about xfs_repair (which I can't find
ATM), having a dozen or so GB swapfile available (again, somewhere other
than the problem FS) should be plenty.

--keith

-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

[toc] | [prev] | [next] | [standalone]

#709

On Tue, 12 Apr 2011 18:04:44 GMT, Tris Orendorff <triso@remove-me.cogeco.ca> wrote:

>Grant <omg@grrr.id.au> burped up warm pablum in
>news:tllsp6ltftsq6ufp048hcc4ivufupgbmki@4ax.com: 
>
>> 
>> Swap space?  RAID10 is best for that, from my reading.  Got to be
>> careful with swap reliability because bad swap will crash the machine
>> and possibly eat your data.  Same as bad memory.
>
> Swap space?  Isn't that useless for a server?  We've found it next-to-useless on our desktops even with the fastest 
>SSDs.

So you'd rather crash when a process needs a large contiguous memory 
block Now!  And, the memory is fragmented because the machine uptime 
is high.

Swap is still relevant to keep a machine running, maybe not a lot of it.  
Somewhere upthread I described using swap for /tmp space overflow as well.  

I've seen swap used when there was ample memory, and the argument above 
is how I've seen it for years, something changed?

Grant.

[toc] | [prev] | [next] | [standalone]

#763

Grant <omg@grrr.id.au> burped up warm pablum in.........................................................................
news:dkqcq698epjubcv8urilvllhoout1f268q@4ax.com: 

> On Tue, 12 Apr 2011 18:04:44 GMT, Tris Orendorff
> <triso@remove-me.cogeco.ca> wrote: 
> 
>>Grant <omg@grrr.id.au> burped up warm pablum in
>>news:tllsp6ltftsq6ufp048hcc4ivufupgbmki@4ax.com: 
>>
>>> 
>>> Swap space?  RAID10 is best for that, from my reading.  Got to be
>>> careful with swap reliability because bad swap will crash the
>>> machine and possibly eat your data.  Same as bad memory.
>>
>> Swap space?  Isn't that useless for a server?  We've found it
>> next-to-useless on our desktops even with the fastest 
>>SSDs.
> 
> So you'd rather crash when a process needs a large contiguous memory 
> block Now!  And, the memory is fragmented because the machine uptime 
> is high

In general, yes.  It is going to crash by swapping and thashing anyway--so why wait?

> Swap is still relevant to keep a machine running, maybe not a lot of
> it.  Somewhere upthread I described using swap for /tmp space overflow
> as well.  
> 
> I've seen swap used when there was ample memory, and the argument
> above is how I've seen it for years, something changed?

Yes!  The 64-bit proccessor is one reason and Java is another.  Four GB isn't enough for the 100 or so processes 
needed for a  64-bit Linux ayatem to run apps.  

Once a Java program hits swap it is lost on the next garbage collection (gc).  The gc has to trace down every objject in 
memory and with millions of objects and the slowdown due to swapping it is a lost cause.

The simple answer is to add ram not swap-space.  

-- 
Tris Orendorff
[ Anyone naming their child should spend a few minutes checking rhyming slang and dodgy sounding names. Brad and 
Angelina failed to do this when naming their kid Shiloh Pitt. At some point, someone at school is going to spoonerise 
her name.
Craig Stark ]

[toc] | [prev] | [next] | [standalone]

#764

On 2011-04-15 21:59, Tris Orendorff <triso@remove-me.cogeco.ca> wrote:
> Grant <omg@grrr.id.au> burped up warm pablum in.........................................................................
> news:dkqcq698epjubcv8urilvllhoout1f268q@4ax.com: 
>
>> On Tue, 12 Apr 2011 18:04:44 GMT, Tris Orendorff
>> <triso@remove-me.cogeco.ca> wrote: 
>> 
>>>Grant <omg@grrr.id.au> burped up warm pablum in
>>>news:tllsp6ltftsq6ufp048hcc4ivufupgbmki@4ax.com: 
>>>
>>>> 
>>>> Swap space?  RAID10 is best for that, from my reading.  Got to be
>>>> careful with swap reliability because bad swap will crash the
>>>> machine and possibly eat your data.  Same as bad memory.
>>>
>>> Swap space?  Isn't that useless for a server?  We've found it
>>> next-to-useless on our desktops even with the fastest 
>>>SSDs.
>> 
>> So you'd rather crash when a process needs a large contiguous memory 
>> block Now!  And, the memory is fragmented because the machine uptime 
>> is high
>
> In general, yes.  It is going to crash by swapping and thashing anyway--so why wait?

Because it is very likely NOT going to crash.


>> Swap is still relevant to keep a machine running, maybe not a lot of
>> it.  Somewhere upthread I described using swap for /tmp space overflow
>> as well.  
>> 
>> I've seen swap used when there was ample memory, and the argument
>> above is how I've seen it for years, something changed?
>
> Yes!  The 64-bit proccessor is one reason and Java is another.  Four
> GB isn't enough for the 100 or so processes needed for a  64-bit Linux
> ayatem to run apps.  

I've used 64-bit Linux on systems with 128 MB (maybe even 64 MB - that
was some time ago). If 4GB isn't enough for you, it's because your
applications are huge, not because of the 64 bit processor.


> Once a Java program hits swap it is lost on the next garbage
> collection (gc).  The gc has to trace down every objject in memory and
> with millions of objects and the slowdown due to swapping it is a lost
> cause.
>
> The simple answer is to add ram not swap-space.  

The simple answer is not to use Java ;-).

Yes, a mark-and-sweep type GC is very likely to thrash if doesn't fit
into RAM. But all the world is not Java, and I've seen applications
which were running fine out of swap space. I've used POVray to render
models several times larger than RAM and got nearly 100% CPU time. As a
rather extreme example a colleague of mine did some simulations in R
which consumed almost 300 GB swap space on a machine with 24 GB RAM but
still got about 50% CPU time (so they would have been only twice as fast
if he had had 324GB RAM).

So as always, the right answer is: It depends.

	hp

[toc] | [prev] | [next] | [standalone]

#765

Peter J. Holzer wrote:
> On 2011-04-15 21:59, Tris Orendorff <triso@remove-me.cogeco.ca> wrote:
>> Grant <omg@grrr.id.au> burped up warm pablum in.........................................................................
>> news:dkqcq698epjubcv8urilvllhoout1f268q@4ax.com: 
>>
>>> On Tue, 12 Apr 2011 18:04:44 GMT, Tris Orendorff
>>> <triso@remove-me.cogeco.ca> wrote: 
>>>
>>>> Grant <omg@grrr.id.au> burped up warm pablum in
>>>> news:tllsp6ltftsq6ufp048hcc4ivufupgbmki@4ax.com: 
>>>>
>>>>> Swap space?  RAID10 is best for that, from my reading.  Got to be
>>>>> careful with swap reliability because bad swap will crash the
>>>>> machine and possibly eat your data.  Same as bad memory.
>>>> Swap space?  Isn't that useless for a server?  We've found it
>>>> next-to-useless on our desktops even with the fastest 
>>>> SSDs.
>>> So you'd rather crash when a process needs a large contiguous memory 
>>> block Now!  And, the memory is fragmented because the machine uptime 
>>> is high
>> In general, yes.  It is going to crash by swapping and thashing anyway--so why wait?
> 
> Because it is very likely NOT going to crash.
> 
> 
>>> Swap is still relevant to keep a machine running, maybe not a lot of
>>> it.  Somewhere upthread I described using swap for /tmp space overflow
>>> as well.  
>>>
>>> I've seen swap used when there was ample memory, and the argument
>>> above is how I've seen it for years, something changed?
>> Yes!  The 64-bit proccessor is one reason and Java is another.  Four
>> GB isn't enough for the 100 or so processes needed for a  64-bit Linux
>> ayatem to run apps.  
> 
> I've used 64-bit Linux on systems with 128 MB (maybe even 64 MB - that
> was some time ago). If 4GB isn't enough for you, it's because your
> applications are huge, not because of the 64 bit processor.
> 
> 

my 64 bit atom based server has 512 Mbytes
  Prefectly happy

64 bit Desktop with 4gigs slows a bit when windows in in virtual box and 
pulls 2 gig out of the pot to run it, BUT  it doesn't crash.

sometimes runs into swap with BIG graphics objects, thats all.


>> Once a Java program hits swap it is lost on the next garbage
>> collection (gc).  The gc has to trace down every objject in memory and
>> with millions of objects and the slowdown due to swapping it is a lost
>> cause.
>>
>> The simple answer is to add ram not swap-space.  
> 
> The simple answer is not to use Java ;-).

Indeed.

> Yes, a mark-and-sweep type GC is very likely to thrash if doesn't fit
> into RAM. But all the world is not Java, and I've seen applications
> which were running fine out of swap space. I've used POVray to render
> models several times larger than RAM and got nearly 100% CPU time. As a
> rather extreme example a colleague of mine did some simulations in R
> which consumed almost 300 GB swap space on a machine with 24 GB RAM but
> still got about 50% CPU time (so they would have been only twice as fast
> if he had had 324GB RAM).
> 
> So as always, the right answer is: It depends.
> 
> 	hp
> 

[toc] | [prev] | [next] | [standalone]

#642

On 6.4.11 5:39 , Keith Keller wrote:
> Hi all,
>
> I am attempting to build a snapshot server for a ~15TB fileserver with
> old fileserver hardware I have on hand.  My initial plan was to use the
> hardware card in the old fileserver in a RAID50 (the card is old enough
> that it doesn't support RAID6 natively) using new 2TB enterprise hard
> drives.  But, as you probably know, these drives are reasonably
> expensive.  So, since this machine will not be used by end-users very
> much, I was contemplating using linux software raid instead, exporting
> desktop-class drives as JBODs and using mdadm to RAID them.
>
> The obvious advantage to this is cost: I can save almost 40% of my
> original estimate by using desktop drives instead, thus fulfilling the
> original meaning of the I of the RAID acronym.  There are other
> advantages, as well, including being able to build a RAID6, which I
> slightly prefer over a RAID50, and having more flexibility later on if I
> want to move to bigger disks.  (Yes, I have seen the documentation
> warning against too-large RAID arrays resulting in a failure during a
> rebuild.)  A tertiary advantage would be that I would learn how to work
> with linux software RAID, a skill I haven't yet acquired.
>
> The disadvantages I can think of are: higher probability of disk
> failures, resulting in more work for me in swapping out and RMAing
> failed drives; potential degradation in performance, due both to RAID in
> software and slower disks; a learning curve for linux RAID; and a
> configuration less likely to be supported by the hardware RAID vendor.
>
> My counters to most of the disadvantages would be that performance only
> has to be decent, not great, on this box; the learning curve shouldn't
> be too bad; and this configuration shouldn't require support from the
> hardware RAID vendor anyway.  The disk failures would be the only issue
> I couldn't counter, except by trying to determine if my labor costs
> would end up being more than the savings in moving to cheaper disks.
>
> My questions:
>
> 1) Has anyone done this before, and if so, what were the results?  Was
> performance acceptable in this configuration?  Are there any gotchas to
> an otherwise workable configuration?
>
> 2) From what I've read so far, using desktop-class disks with linux
> software RAID should not be a major problem, unlike using them on a true
> hardware RAID card.  Is this reasonably accurate?  If not, are there
> links that describe the difficulties?
>
> 3) Suppose that my RAID6 starts out using 12 2TB disks, with three free
> drive bays (one would be a hot spare).  Later on, I want to seamlessly
> replace the 2TB disks with 3TB or larger disks.  Can mdadm grow an array
> like this if, say, I replace one drive, rebuild, and repeat until I've
> replaced all 12 disks with larger ones?  Or will the new 3TB disks only
> be used up to 2TB, the size of the original disks?
>
> Thanks for any advice or pointers you can provide!
>
> --keith
>

A consideration not shown yet in this thread: If the hardware RAID
controller breaks, you'll lose all the data if you do not have a
similar controller as a spare.

A software array is easier to rescue after a hardware loss.

-- 

Tauno Voipio
tauno voipio (at) iki fi

[toc] | [prev] | [next] | [standalone]

#646

On Fri, 08 Apr 2011 21:38:48 +0300, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:

>On 6.4.11 5:39 , Keith Keller wrote:
>> Hi all,
>>
>> I am attempting to build a snapshot server for a ~15TB fileserver with
>> old fileserver hardware I have on hand.  My initial plan was to use the
>> hardware card in the old fileserver in a RAID50 (the card is old enough
>> that it doesn't support RAID6 natively) using new 2TB enterprise hard
>> drives.  But, as you probably know, these drives are reasonably
>> expensive.  So, since this machine will not be used by end-users very
>> much, I was contemplating using linux software raid instead, exporting
>> desktop-class drives as JBODs and using mdadm to RAID them.
>>
>> The obvious advantage to this is cost: I can save almost 40% of my
>> original estimate by using desktop drives instead, thus fulfilling the
>> original meaning of the I of the RAID acronym.  There are other
>> advantages, as well, including being able to build a RAID6, which I
>> slightly prefer over a RAID50, and having more flexibility later on if I
>> want to move to bigger disks.  (Yes, I have seen the documentation
>> warning against too-large RAID arrays resulting in a failure during a
>> rebuild.)  A tertiary advantage would be that I would learn how to work
>> with linux software RAID, a skill I haven't yet acquired.
>>
>> The disadvantages I can think of are: higher probability of disk
>> failures, resulting in more work for me in swapping out and RMAing
>> failed drives; potential degradation in performance, due both to RAID in
>> software and slower disks; a learning curve for linux RAID; and a
>> configuration less likely to be supported by the hardware RAID vendor.
>>
>> My counters to most of the disadvantages would be that performance only
>> has to be decent, not great, on this box; the learning curve shouldn't
>> be too bad; and this configuration shouldn't require support from the
>> hardware RAID vendor anyway.  The disk failures would be the only issue
>> I couldn't counter, except by trying to determine if my labor costs
>> would end up being more than the savings in moving to cheaper disks.
>>
>> My questions:
>>
>> 1) Has anyone done this before, and if so, what were the results?  Was
>> performance acceptable in this configuration?  Are there any gotchas to
>> an otherwise workable configuration?
>>
>> 2) From what I've read so far, using desktop-class disks with linux
>> software RAID should not be a major problem, unlike using them on a true
>> hardware RAID card.  Is this reasonably accurate?  If not, are there
>> links that describe the difficulties?
>>
>> 3) Suppose that my RAID6 starts out using 12 2TB disks, with three free
>> drive bays (one would be a hot spare).  Later on, I want to seamlessly
>> replace the 2TB disks with 3TB or larger disks.  Can mdadm grow an array
>> like this if, say, I replace one drive, rebuild, and repeat until I've
>> replaced all 12 disks with larger ones?  Or will the new 3TB disks only
>> be used up to 2TB, the size of the original disks?
>>
>> Thanks for any advice or pointers you can provide!
>>
>> --keith
>>
>
>A consideration not shown yet in this thread: If the hardware RAID
>controller breaks, you'll lose all the data if you do not have a
>similar controller as a spare.
>
>A software array is easier to rescue after a hardware loss.

Yes, the big advantage of Linux md is that the disks can be read elsewhere.
I thought that was a given, since we're in a linux group?

Grant.

[toc] | [prev] | [next] | [standalone]

#651

On 06.04.2011 04:39, Keith Keller wrote:
> 
> The obvious advantage to this is cost: I can save almost 40% of my
> original estimate by using desktop drives instead, thus fulfilling the
> original meaning of the I of the RAID acronym.  There are other
> advantages, as well, including being able to build a RAID6, which I
> slightly prefer over a RAID50, and having more flexibility later on if I
> want to move to bigger disks.  (Yes, I have seen the documentation
> warning against too-large RAID arrays resulting in a failure during a
> rebuild.)  A tertiary advantage would be that I would learn how to work
> with linux software RAID, a skill I haven't yet acquired.

"Enterprise hard drives" can mean at least two different things: either
the drives are high-performance SATA or SAS drives (10k or 15k RPM), or
they are regular high-end (7.2k RPM) SATA drives with non-sequential
serial numbers.

In the latter case, the drives are really regular desktop drives,
sometimes fitted with slightly more cache, but the drives are from
different batches. This saves you from experiencing multiple drive
failures over a short time period due to some manufacturing defect.

> The disadvantages I can think of are: higher probability of disk
> failures, resulting in more work for me in swapping out and RMAing
> failed drives; potential degradation in performance, due both to RAID in
> software and slower disks; a learning curve for linux RAID; and a
> configuration less likely to be supported by the hardware RAID vendor.

Another issue is that while most hardware RAID cards can cope with
failing drive electronics that hang the bus, simple on-board/PCIe SATA
controllers are usually not so forgiving and may cause a system freeze
or a kernel OOPS, the latter possibly causing severe file system
corruption (I've experienced it a few times).

Also, most hardware RAID controllers will perform an automatic block
reallocation when it encounters a bad block during read or verify. This
will be logged, so you'll usually get ample warning before a drive failure.

> My questions:
> 
> 1) Has anyone done this before, and if so, what were the results?  Was
> performance acceptable in this configuration?  Are there any gotchas to
> an otherwise workable configuration?

I've used software RAID on occations, mostly with device-mapper but I've
used md a few times as well. No problems to speak of (or at all, really).

Neither the MD nor device-mapper reads the S.M.A.R.T. data from the
drives in the array. mdadm can send a notification by mail when a drive
fails, but I usually monitor the S.M.A.R.T. data from each drive with
smartd as well.

> 2) From what I've read so far, using desktop-class disks with linux
> software RAID should not be a major problem, unlike using them on a true
> hardware RAID card.  Is this reasonably accurate?  If not, are there
> links that describe the difficulties?

There are no issues that I'm aware of with using desktop class drives
with a hardware RAID card either, other than the obvious reduction in
performance if you're going from 15k or 10k RPM drives to 7.2k RPM or lower.

> 3) Suppose that my RAID6 starts out using 12 2TB disks, with three free
> drive bays (one would be a hot spare).  Later on, I want to seamlessly
> replace the 2TB disks with 3TB or larger disks.  Can mdadm grow an array
> like this if, say, I replace one drive, rebuild, and repeat until I've
> replaced all 12 disks with larger ones?  Or will the new 3TB disks only
> be used up to 2TB, the size of the original disks?

Your data will be striped across the 2Tb drives, so replacing one of
them with a 3Tb drive will leave 1Tb unused (or leave you with a
degraded RAID set if the 2Tb drives are emulating 512 byte sectors,
something the 3Tb drive won't be doing).

Since most of the other posts in this thread claim that software RAID
will give better performance, I thought I'd chime in with the exact
opposite viewpoint: Unless you're using a so-called 'fakeRAID'
controller (one without a CPU), a hardware RAID controller is likely to
perform slightly better for read operations due to caching, and perhaps
considerably better when writing.

Yes, the CPUs on RAID controllers are usually quite anemic. The reason
for this is that the complexity of the mathematical operations involved
with generating RAID stripes range from completely trivial (RAID 0, 1,
5, 10, 50) to rather simple (RAID 6, 60). Even with a slow CPU
generating stripe data, the limiting factor is more likely to be the
drives or the host OS.

However, there is one other major difference between hardware and
software RAID which may severely affect write speeds:

- A hardware RAID controller receives the data over the PCIe bus,
generates the stripes, and pushes the data to the drives.

- A software RAID driver receives the data from the OS, generates the
stripes, and pushes the data to the controller(s) over the PCIe bus.

As you can see, a software RAID setup means that all stripes have to be
transferred across the bus. For RAID 1 or 10 this means a 100% overhead
for any write operation; for RAID 5, 6, 50 or 60 the overhead percentage
varies with the number of drives in the set (more drives are better).

This may or may not be significant for a given setup. If you're building
a RAID 6 set with 12 reasonably fast 7.2k RPM SATA-II drives and a good
PCIe based motherboard, the 20% overhead for the parity blocks may not
be noticable.

Whatever you choose, make sure you verify your array on a regular basis.
You want to discover that bad block when the array is operational, not
during a rebuild operation. Also, if you're going for desktop drives, I
would really recommend a hot or cold spare.

[toc] | [prev] | [next] | [standalone]

#654

On 2011-04-09, KR <kristian.rasmussen@broadpark.no.spam.com> wrote:
>
> "Enterprise hard drives" can mean at least two different things: either
> the drives are high-performance SATA or SAS drives (10k or 15k RPM), or
> they are regular high-end (7.2k RPM) SATA drives with non-sequential
> serial numbers.

For my purposes, ''enterprise'' drives means ''whatever the hardware
RAID vendor officially claims to support''.  I have had the vendor
refuse to support a RAID array that was built with ''desktop'' disks.
And since the card is out of warranty anyway, the advantages to
preserving my support path are minimal.

> Whatever you choose, make sure you verify your array on a regular basis.
> You want to discover that bad block when the array is operational, not
> during a rebuild operation. Also, if you're going for desktop drives, I
> would really recommend a hot or cold spare.

Yes, of course.  :)  On my hardware RAID arrays I do monthly verifies,
and I don't see any reason to deviate from that.  (The 3ware cards used
to (not sure if they still do) default to weekly verifies; I thought
this was too much wear on the drives.)  Having a spare desirable
probably depends on the particular application, but in this case I will
certainly have both a hot and a cold spare handy.

--keith

-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

[toc] | [prev] | [next] | [standalone]

#659

On Sat, 9 Apr 2011 10:32:44 -0700, Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:

>On 2011-04-09, KR <kristian.rasmussen@broadpark.no.spam.com> wrote:
>>
>> "Enterprise hard drives" can mean at least two different things: either
>> the drives are high-performance SATA or SAS drives (10k or 15k RPM), or
>> they are regular high-end (7.2k RPM) SATA drives with non-sequential
>> serial numbers.
>
>For my purposes, ''enterprise'' drives means ''whatever the hardware
>RAID vendor officially claims to support''.  I have had the vendor
>refuse to support a RAID array that was built with ''desktop'' disks.
>And since the card is out of warranty anyway, the advantages to
>preserving my support path are minimal.

Since I take the I in RAID seriously, I do not expect to have to run 
enterprise drives in a RAID setup.  If I bought an enterprise drive, it 
should be as or more reliable than a RAID of 'consumer' desktop drives.

And, I've read of no use limitation for Seagate drives (Yeah, I stay with 
Seagate, even when every drive I bought last year required a BIOS update).

I've suffered one bad drive from Seagate in over ten years, and that one 
came from an 'iffy' source that might not have treated the drive properly.
>
>> Whatever you choose, make sure you verify your array on a regular basis.
>> You want to discover that bad block when the array is operational, not
>> during a rebuild operation. Also, if you're going for desktop drives, I
>> would really recommend a hot or cold spare.
>
>Yes, of course.  :)  On my hardware RAID arrays I do monthly verifies,
>and I don't see any reason to deviate from that.  (The 3ware cards used
>to (not sure if they still do) default to weekly verifies; I thought
>this was too much wear on the drives.)  Having a spare desirable
>probably depends on the particular application, but in this case I will
>certainly have both a hot and a cold spare handy.

How do you verify?

Rsync with checksums turned on, against the backup okay?  I'm tempted to 
spin down the backup 2TB drive too, it's one of those Seagate 5900rpm 
things.  Eventually I'll take a backup onto a removable drive or external 
drive, depends if I buy  an external case or a hotswap drive bay.  I'll 
soon buy a 1TB cold spare as well, but they're usually not too far away.

In fact the borrowed 1.5TB drive I'm using is a friend's cold spare, he's 
running 6 x 1.5TB in a Qnap NAS box -- it runs some form of Linux from a 
strange memory type BOM?  What's that?

I'd be tempted to go hardware RAID down the track, rather than build a 
Linux server box like I have now.  It's speed is a bit disappointing, 
overall seems to be only 16.4MB/s for 1.1TB (1157035644 x 1K blocks) 
written from an external drive in 1176 minutes, unless I goofed the calc.

I saw peak write rates of 127MB/s, then hours of about 4MB/s while 140,000 
odd photo files being copied.

Then I ran an rsync:

root@pooh:~# rsync -av /home/backup3/* /home/raid/b
sending incremental file list
backup-raid-3/ntfs1/GrantsStuff/P-Data/Thunderbird/upload/BootCatalog.cat
backup-raid-3/ntfs1/GrantsStuff/P-Data/Thunderbird/upload/Microsoft Corporation.img
backup-raid-3/ntfs1/GrantsStuff2/P-Data/Thunderbird/upload/BootCatalog.cat
backup-raid-3/ntfs1/GrantsStuff2/P-Data/Thunderbird/upload/Microsoft Corporation.img

Dunno why those four files not copied first time, I'll do another rsync with 
checksums before clearing the borrowed drive.  I used 'cp -a ...' for the main 
transfer from eSATA external drive to the new RAID6, after the sync was finished.

Top showed the box usage between 2.5 to 3 during that copy operation.

Extra two SATA channels provided by a JMicron JMB362/363 PCIE single lane card.

The box has a four lane PCIE socket, wish I could find a SATA card fits that.

Intel ICH9R for the six by 1TB RAID drives.

Grant.
>
>--keith

[toc] | [prev] | [next] | [standalone]

#660

On 2011-04-10, Grant <omg@grrr.id.au> wrote:
>
> Since I take the I in RAID seriously, I do not expect to have to run 
> enterprise drives in a RAID setup.

The I in RAID now apparently means "independent", not "inexpensive".

> And, I've read of no use limitation for Seagate drives (Yeah, I stay with 
> Seagate, even when every drive I bought last year required a BIOS update).

I like Seagate drives, but I don't like how they handle RMAs--end users
must return drives one at a time.  Western Digital will accept multiple
drives in a single RMA.

> How do you verify?

A hardware controller usually has a verify command.  I assume that there
is a way to send a verify to a linux-managed array as well, but I would
need to read the documentation to be sure.

> Rsync with checksums turned on, against the backup okay?

No, a RAID verify operation is internal to the array.

--keith

-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

[toc] | [prev] | [next] | [standalone]

#661

On 10.04.2011 03:59, Keith Keller wrote:
> 
> A hardware controller usually has a verify command.  I assume that there
> is a way to send a verify to a linux-managed array as well, but I would
> need to read the documentation to be sure.

Writing the string "check" to /sys/block/[array name]/md/sync_action
initiates a verify.

I haven't found a way to verify LVM mirror sets other than reading the
entire device file (which really isn't good enough, as it won't detect
bad parity blocks).

[toc] | [prev] | [next] | [standalone]

#662

On Sun, 10 Apr 2011 04:32:46 +0200, KR <kristian.rasmussen@broadpark.no.spam.com> wrote:

>On 10.04.2011 03:59, Keith Keller wrote:
>> 
>> A hardware controller usually has a verify command.  I assume that there
>> is a way to send a verify to a linux-managed array as well, but I would
>> need to read the documentation to be sure.
>
>Writing the string "check" to /sys/block/[array name]/md/sync_action
>initiates a verify.

Oh okay, penny dropped.  By verify you mean to make sure the RAID6 
checksums are okay?  Not a copy verify.  I'll do that too, I recall 
reading about it somewhere.
>
>I haven't found a way to verify LVM mirror sets other than reading the
>entire device file (which really isn't good enough, as it won't detect
>bad parity blocks).

I avoided LVM, so I'm just wanting to verify the huge 1.1TB write to a new 
RAID6 is in one piece so I can zero and return a borrowed hard drive.

The second RAID6 will be loaded from my own backups and should match 
roughly the transfer I've just done overnight, but with a separate copy 
path so I do not duplicate some potential dataloss error, I'm hoping.

That way I hope to have some redundancy, and a loose connection between the 
two RAID arrays, rather than a straight mirror.  My intention is for the 
slow RAID to be available read-only, the fast one for day to day read-write 
access.

Then let experience guide me over the next few months as to what needs 
changing.  At least nobody here has pointed out a Bad Thing for what I'm 
doing.  Certainly it may not be the best thing, but we all have budgets 
and our own needs to consider :)

Thanks to all in this thread, it's been interesting, educational.

Grant.

[toc] | [prev] | [next] | [standalone]

#663

On 2011-04-10, Grant <omg@grrr.id.au> wrote:
>
> Thanks to all in this thread, it's been interesting, educational.

I've been pleasantly surprised!  I was fearful that the answers to my
questions would be "what are you, a freaking moron?  Don't do that!"
But I'm glad the thread has helped others as well.

--keith

-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

[toc] | [prev] | [next] | [standalone]

#664

On 2011-04-09, KR <kristian.rasmussen@broadpark.no.spam.com> wrote:
> On 06.04.2011 04:39, Keith Keller wrote:
>> 
>> The obvious advantage to this is cost: I can save almost 40% of my
>> original estimate by using desktop drives instead, thus fulfilling the
>> original meaning of the I of the RAID acronym.  There are other
>> advantages, as well, including being able to build a RAID6, which I
>> slightly prefer over a RAID50, and having more flexibility later on if I
>> want to move to bigger disks.  (Yes, I have seen the documentation
>> warning against too-large RAID arrays resulting in a failure during a
>> rebuild.)  A tertiary advantage would be that I would learn how to work
>> with linux software RAID, a skill I haven't yet acquired.
>
> "Enterprise hard drives" can mean at least two different things: either
> the drives are high-performance SATA or SAS drives (10k or 15k RPM), or
> they are regular high-end (7.2k RPM) SATA drives with non-sequential
> serial numbers.
>
> In the latter case, the drives are really regular desktop drives,
> sometimes fitted with slightly more cache, but the drives are from
> different batches. This saves you from experiencing multiple drive
> failures over a short time period due to some manufacturing defect.

I researched RAID a couple of months ago and found a lot of
references that indicated something akin to a 'limited duration
recalibration' (or similar wording) that is generally a feature
of enterprise- or raid-edition disks but not of desktop units.
The idea is a desktop disk can go out to lunch for several
seconds to recalibrate itself, long enough to cause the RAID
controller (or mdadm or LVM) to declare the physical disk drive
to be dead.

Are you saying 7200rpm disk drives have no such difference
between desktop varieties and enterprise- or raid-edition models?

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

[toc] | [prev] | [next] | [standalone]

#665

On 04/10/11 09:17, Robert Riches wrote:
> On 2011-04-09, KR <kristian.rasmussen@broadpark.no.spam.com> wrote:
>> On 06.04.2011 04:39, Keith Keller wrote:
>>>
>>> The obvious advantage to this is cost: I can save almost 40% of my
>>> original estimate by using desktop drives instead, thus fulfilling the
>>> original meaning of the I of the RAID acronym.  There are other
>>> advantages, as well, including being able to build a RAID6, which I
>>> slightly prefer over a RAID50, and having more flexibility later on if I
>>> want to move to bigger disks.  (Yes, I have seen the documentation
>>> warning against too-large RAID arrays resulting in a failure during a
>>> rebuild.)  A tertiary advantage would be that I would learn how to work
>>> with linux software RAID, a skill I haven't yet acquired.
>>
>> "Enterprise hard drives" can mean at least two different things: either
>> the drives are high-performance SATA or SAS drives (10k or 15k RPM), or
>> they are regular high-end (7.2k RPM) SATA drives with non-sequential
>> serial numbers.
>>
>> In the latter case, the drives are really regular desktop drives,
>> sometimes fitted with slightly more cache, but the drives are from
>> different batches. This saves you from experiencing multiple drive
>> failures over a short time period due to some manufacturing defect.
> 
> I researched RAID a couple of months ago and found a lot of
> references that indicated something akin to a 'limited duration
> recalibration' (or similar wording) that is generally a feature
> of enterprise- or raid-edition disks but not of desktop units.
> The idea is a desktop disk can go out to lunch for several
> seconds to recalibrate itself, long enough to cause the RAID
> controller (or mdadm or LVM) to declare the physical disk drive
> to be dead.

IMHO, you and most of other posters forget to mention the ZFS and
RAID-Z; See also http://blogs.sun.com/bonwick/en_US/category/ZFS,
http://queue.acm.org/detail.cfm?id=1317400 and http://zfsonlinux.org/

@OP, if we keep aside the CDDL v/s GPL thread the Native ZFS for Linux
also seems to be good a option, though, I have not tested booting Linux
and, or FreeBSD of off a ZFS volume or root, but booting both the Linux
and FreeBSD from a tiny (512 MiB) SD/MMC card worked like charm :) This,
however, is an experimental machine, so I would be interested to hear if
anyone else ever used a similar setup for a production server.

> Are you saying 7200rpm disk drives have no such difference
> between desktop varieties and enterprise- or raid-edition models?

-- 
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/      Visit: http://counter.li.org/

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web