Re: is hammer for us
I was under the impression HAMMER was a parallel filesystem. sorry On Wed, Aug 12, 2009 at 1:04 AM, Matthew Dillon wrote: > > : > :The I/O bottleneck is coming from the disk subsystem and network. I > :was wondering if HAMMER can do parallel filesystem implementation > :similar to GPFS or Lustre. > : > :Also, the reads/writes are random access there is very little > :sequential streaming, but the files are large.Each file is around 30GB > :each > > It can do master->multi_slave replication if that is what you mean. > I don't know how that might compare to GPFS or Lustre. You are going > to have more choices in linux-land then in BSD-land, particularly if > you have a large array of drives. > > If there is an I/O bottleneck from the disks due to random access > seeks the only solution is more spindles. > > If you can stage the data in any way a large SSD (solid state drive) > might help. e.g. one or more 256G SSDs for data staging eliminates > the seek bottlneck and probably also eliminates the need for large > amounts of ram in the machines. > > -Matt > >
Re: is hammer for us
: :The I/O bottleneck is coming from the disk subsystem and network. I :was wondering if HAMMER can do parallel filesystem implementation :similar to GPFS or Lustre. : :Also, the reads/writes are random access there is very little :sequential streaming, but the files are large.Each file is around 30GB :each It can do master->multi_slave replication if that is what you mean. I don't know how that might compare to GPFS or Lustre. You are going to have more choices in linux-land then in BSD-land, particularly if you have a large array of drives. If there is an I/O bottleneck from the disks due to random access seeks the only solution is more spindles. If you can stage the data in any way a large SSD (solid state drive) might help. e.g. one or more 256G SSDs for data staging eliminates the seek bottlneck and probably also eliminates the need for large amounts of ram in the machines. -Matt
Re: is hammer for us
The I/O bottleneck is coming from the disk subsystem and network. I was wondering if HAMMER can do parallel filesystem implementation similar to GPFS or Lustre. Also, the reads/writes are random access there is very little sequential streaming, but the files are large.Each file is around 30GB each On Tue, Aug 11, 2009 at 11:42 PM, Matthew Dillon wrote: > > :I am a student doing fluid dynamics research. We generate a lot of > :data (close to 2TB a day). We are having scalability problems with > :NFS. We have 2 Linux servers with 64GB of RAM, and they are serving > :the files. > : > :We are constantly running into I/O bottle neck problems. Would hammer > :fix the scalability problems? > : > :TIA > > If you are hitting an I/O bottleneck you need to determine where the > bottleneck is. Is it in the actual accesses to the disk subsystem? > Are the disks seeking randomly or accessing data linearly? Is the > transfer rate acceptable? Is it the network? Is it the NFS > implementation? Is it the underlying filesystem on the server? Are > there parallelism issues? > > You need to find the answer to those questions before you can determine > a solution. > > Serving large files typically does not create a filesystem bottleneck. > i.e. any filesystem, even something like ZFS, should still be able > to serve large linear files at the platter rate. Having a lot of ram > only helps if there is some locality of reference in the data set. > i.e. if the data set is much larger then available memory but there > is no locality of reference and the disk drives are hitting their seek > limits, no amount of ram will solve the problem. > > (DragonFly's 64 bit support isn't reliable yet, so DragonFly can't > access that amount of ram right now anyhow). > > -Matt > Matthew Dillon > >
Re: is hammer for us
:I am a student doing fluid dynamics research. We generate a lot of :data (close to 2TB a day). We are having scalability problems with :NFS. We have 2 Linux servers with 64GB of RAM, and they are serving :the files. : :We are constantly running into I/O bottle neck problems. Would hammer :fix the scalability problems? : :TIA If you are hitting an I/O bottleneck you need to determine where the bottleneck is. Is it in the actual accesses to the disk subsystem? Are the disks seeking randomly or accessing data linearly? Is the transfer rate acceptable? Is it the network? Is it the NFS implementation? Is it the underlying filesystem on the server? Are there parallelism issues? You need to find the answer to those questions before you can determine a solution. Serving large files typically does not create a filesystem bottleneck. i.e. any filesystem, even something like ZFS, should still be able to serve large linear files at the platter rate. Having a lot of ram only helps if there is some locality of reference in the data set. i.e. if the data set is much larger then available memory but there is no locality of reference and the disk drives are hitting their seek limits, no amount of ram will solve the problem. (DragonFly's 64 bit support isn't reliable yet, so DragonFly can't access that amount of ram right now anyhow). -Matt Matthew Dillon
is hammer for us
I am a student doing fluid dynamics research. We generate a lot of data (close to 2TB a day). We are having scalability problems with NFS. We have 2 Linux servers with 64GB of RAM, and they are serving the files. We are constantly running into I/O bottle neck problems. Would hammer fix the scalability problems? TIA
