On Mar 04, 2009 09:22 +, Daire Byrne wrote:
- Andreas Dilger adil...@sun.com wrote:
Secondly, with small files there is also the overhead of creating
the many small files on the MDS, which will likely take as long
as the RPCs being sent to the OSTs with data. There is not
Rayentray,
- Rayentray Tappa rtappa.ascen...@gmail.com wrote:
Hi List,
I'm working for a small government organization in South America, and
in our quest for a large distributed storage solution we ran across
Lustre.
We have some servers in which we're trying to build a prototype to
On Wed, 2009-03-04 at 11:09 +, Daire Byrne wrote:
Rayentray,
- Rayentray Tappa rtappa.ascen...@gmail.com wrote:
Hi List,
I'm working for a small government organization in South America, and
in our quest for a large distributed storage solution we ran across
Lustre.
We have
Rayentray,
- Rayentray Tappa rtappa.ascen...@gmail.com wrote:
I'm testing this in order to build a large system later, where high
availability of the data store is a must - so we do want to check how
this works, what involves to configure it and what may happen in case
of failure and how
Hi,
I created an OST today by running:
mkfs.lustre --fsname=testfs --ost --mgsnode=192.168.6@tcp /dev/sda3
(ltcl list_nids in the mdt/mgs gave me the 192.168.6@tcp hint)
When I want to mount it, I get:
mount -t lustre /dev/sda3 /mnt/test/ost0/mount.lustre: mount /dev/sda3
at
On Wed, 2009-03-04 at 12:11 -0500, Ms. Megan Larko wrote:
Greetings,
I have a Lustre OSS with eleven (0-11) OSTs. Every once in a while
the OSS hosting the OSTs fails with a kernel panic.
To be clear, what you are reporting is not a kernel panic. It is a
watchdog timeout. Kernel panics
Brian,
- Brian J. Murrell brian.murr...@sun.com wrote:
On Wed, 2009-03-04 at 17:03 +, Daire Byrne wrote:
Once you move to LVM then you can snapshot the MDT and mount that without
unmounting the production MDT. You should probably destroy the snapshot
afterwards as it affects
On Wed, 2009-03-04 at 17:42 +, Daire Byrne wrote:
Brian,
Hi Daire,
I looked at zumastor. Although it didn't get any slower with extra snapshots
it took quite a hit (~ x6 drop in writes) with just a single snapshot.
Ouch!
Far more promising is the port of zumastor exceptions to the
Andreas Dilger wrote:
On Mar 03, 2009 17:15 -0600, Nirmal Seenu wrote:
mkfs.lustre --fsname=lqcdproj --ost --mgsnode=iblust...@tcp1
--mkfsoptions=-m 0 --index= --reformat /dev/md2
I received these error messages when I tried to mount it for the first time:
Mar 3 16:19:53 lustre1
e2scan will show me all the files that have changed from a date, but
I want to know all the files that have not changed sense some date.
The goal is to make a system for purging scratch spaces that is fast,
and minimum wear on the filesystem.
How are groups doing this now? Are you using
The e2scan shipped from sun's rpms does not support sqlite3 out of
the box:
rpm -qf /usr/sbin/e2scan
e2fsprogs-1.40.7.sun3-0redhat
e2scan: sqlite3 was not detected on configure, database creation is
not supported
Should I just rebuilt only e2scan?
Brock Palen
www.umich.edu/~brockp
Center
Hello all
I am running test between an X4150 and SGI Altix with luster 1.6.6 and I
can see a read performance drop on the SGI.
Numbers:
X4150
dd if=/dev/zero of=/mnt/exec4_client_ib/mike/4/bigfile bs=4096k
count=1 (336MB/s) this a folder with a stripe of 4 for all tests
dd
What page size are you running on IA64? What networking?
Kevin
Michel Dionne wrote:
Hello all
I am running test between an X4150 and SGI Altix with luster 1.6.6 and I
can see a read performance drop on the SGI.
Numbers:
X4150
dd if=/dev/zero of=/mnt/exec4_client_ib/mike/4/bigfile
On Wed, 2009-03-04 at 16:27 -0500, Osvaldo Rentas wrote:
Hello,
I am working with a user that has Fortran code that opens 24.000
files and keeps them open during execution. We had to adjust our
kernel parameters to allow this to happen, since Linux cuts you off at
1024 by default.
Lustre does not impose maximum number of open files, but practically it
depends on amount of RAM on the MDS.
There are no tables for open files on the MDS, as they are only linked
in a list to a given client's export.
Each client process probably has a limit of several thousands of open
files
15 matches
Mail list logo
