Date: Wed, 25 Jan 2006 01:07:04 +0300 From: Sergey Lungu <sergey.lungu@gmail.com> To: Eric Anderson <anderson@centtech.com> Cc: freebsd-geom@freebsd.org Subject: Re: GEOM stripe + concat Message-ID: <20060125010704.54736edd.sergey.lungu@gmail.com> In-Reply-To: <43D6A1E9.2070207@centtech.com> References: <20060122192257.273734cf.sergey.lungu@gmail.com> <20060124232443.2e252b87.sergey.lungu@gmail.com> <43D6985A.1030101@centtech.com> <20060125004419.17dd39b1.sergey.lungu@gmail.com> <43D6A1E9.2070207@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 24 Jan 2006 15:53:45 -0600 Eric Anderson <anderson@centtech.com> wrote: > Sergey Lungu wrote: > > On Tue, 24 Jan 2006 15:12:58 -0600 Eric Anderson > > <anderson@centtech.com> wrote: > > > > > >> Sergey Lungu wrote: > >> > >>> On Sun, 22 Jan 2006 19:22:57 +0300 I wrote: > >>> > >>> > >>> > >>>> Hello, > >>>> > >>>> I have FreeBSD 6.0-RELEASE running on my FTP server. There are > >>>> three disks on that box: two identical 120GB and one 300GB. I am > >>>> using gvinum for stripping between first two disks. I am going to > >>>> give gstripe a try, sine gvinum is too unstable. > >>>> > >>>> > >>> Since nobody has answered my question, possibly it was too silly, > >>> I decided to experiment a bit. I'll answer my questions: > >>> > >>> > >>> > >>>> Am I able to concatenate created stripe with 300GB disk? > >>>> > >>>> > >>> Yes, you can! > >>> > >>> > >>> > >>>> And is it wise at all? > >>>> > >>>> > >>> I have made some simple benchmarking on three different > >>> geometries. Legend: > >>> a * b - stripping between a and b > >>> a + b - concatenation of a and b > >>> ad1 - 120GB disk > >>> ad2 - 120GB disk > >>> ad3 - 300GB disk > >>> > >>> I tried to upload and then download a 700MB movie. Here are my > >>> results: > >>> > >>> ad1 * ad2: > >>> Uploading: 1m8.406s > >>> Downloading: 1m4.656s > >>> > >>> ad1 * ad2 + ad3: > >>> Uploading: 1m4.115s > >>> Downloading: 1m4.962s > >>> > >>> ad1 + ad2 + ad3: > >>> Uploading: 1m4.110s > >>> Downloading: 1m4.971s > >>> > >>> Conclusion: > >>> There is no big difference between all this geometries in FTP > >>> context, or possibly there are some on high load!? > >>> > >>> > >> I'm not sure the details of your tests, since 'upload and then > >> download' doesn't really explain the test, however I'm guessing you > >> were limited by network or the destination rather than the local > >> disk > >> - 1m 4s looks alot like 100mbit to me. > >> > > > > Yes, we have 100mbit network. > > > > > >> You should try one of the many benchmarking tools as a first start > >> (try iozone, or bonnie, etc). > >> > > > > I'm not interested in real disk performance, since this box is used > > only for ftp. Probably I was wrong from the begining and I am > > limited only by the network speed, so software RAID is not the > > right way to boost our ftp server :) > > > > Well, I guess it depends on the files, and the usage. It could be > that you are using much less than 100mbit normally, due to the > transfer of random small files to many clients. I would guess that > if you are not hitting the 100mbit network wall yet, you could > benefit from a stripe of multiple disks, and a larger amount of > available memory. If all the files you are serving are large > (hundreds of megabytes) then you probably won't be disk bound. This server is mostly used to share movies in our hostel, so files are about 700MB or 4GB (DVD images) :) > >> Also, concat won't give you any performance increase, but striping > >> could. You could easily test your 700mb file by doing something > >> like this: > >> > >> dd if=/path/to/700mb-file of=/dev/null bs=1m > >> > > > > I don't think that stripping between two disks can give some > > significant performance boost (I may be wrong, of course), > > especially in ftp context. > > > > Well, stripes can definitely increase disk performance, that's the > whole idea. Otherwise, one wouldn't use it, as it increases risk of > failure (without the use of a parity drive). Unfortunately we don't have enough disks for parity. Does this mean that you suggest to use a+b+c instead? > > I think I'll use a*b+c geometry, but the question is: Will I have > > the same problems with gstripe+gconcat as with gvinum? :) > > I don't think anyone could answer that without information on what > problems you did see with gvinum. We have rather unstable power supply. This is the main problem. One of the disks went down after power jump and now I have to resetconfig (gvinum does not have this one, so this is another inconvenience) and then configure it again after each crash. This is the only sollution I've found. -- Sergey Lungu Return on investments won't.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060125010704.54736edd.sergey.lungu>