But the client is doing a lstat on /mnt/lustre_mail_fs, not /mnt/
lustre -- what is the mount command again?
On Jul 16, 2010, at 6:50 PM, William Olson
wrote:
> On 7/16/2010 5:41 PM, Kevin Van Maren wrote:
>> Looks like a problem with your mount point. What are the
>> permissions on the c
On 7/16/2010 5:41 PM, Kevin Van Maren wrote:
> Looks like a problem with your mount point. What are the permissions
> on the client directory?
>
NFSServer/Lustre Client
Lustre mounted:
drwxrwxrwx 29 root root 4.0K Jul 12 17:03 lustre_mail_fs
Lustre not mounted:
drwxrwxrwx 2 root root 4.0K Jun 10
Looks like a problem with your mount point. What are the permissions
on the client directory?
On Jul 16, 2010, at 6:23 PM, William Olson
wrote:
> On 7/16/2010 5:12 PM, Andreas Dilger wrote:
>>
>>> Well that improved the debug level, but didn't reveal any -2
>>> errors.. In fact I can't
On 7/16/2010 5:12 PM, Andreas Dilger wrote:
>
>> Well that improved the debug level, but didn't reveal any -2 errors.. In
>> fact I can't seem to find a line with an error in it... Is there a specific
>> verbiage used on error lines that I can grep for? 90% is "Process entered"
>> or "Process
On 2010-07-16, at 18:09, William Olson wrote:
> On 7/16/2010 4:50 PM, Andreas Dilger wrote:
Then search through the logs for -2 errors (-EPERM).
>>
>
> Well that improved the debug level, but didn't reveal any -2 errors.. In
> fact I can't seem to find a line with an err
On 7/16/2010 4:50 PM, Andreas Dilger wrote:
>
> Hmm, you must have a low debug level. Please try enabling full debug during
> the mount:
>
> # lctl clear
> # DBGSAVE=$(lctl get_param -n debug)
> # lctl set_param debug=-1
> # mount ...
> # lctl dk /tmp/debug
> # lctl set_param debug="$DBGSAVE"
>
>
On 7/16/2010 4:35 PM, Kevin Van Maren wrote:
> Without more information about the server error messages and exact nfs
> configuration, not sure anyone can help more than this. A common
> problem with Lustre NFS exports, one that isn't due to normal
> NFS/configuration issues, is getting error -
On 2010-07-16, at 16:55, William Olson wrote:
> On 7/16/2010 9:16 AM, Andreas Dilger wrote:
>> My only other suggestion is to dump the Lustre kernel debug log on the NFS
>> server after a mount failure to see where/why it is getting the permission
>> error.
>>
>> # lctl clear
>> # (mount NFS cli
On 2010-07-16, at 17:35, Kevin Van Maren wrote:
> Without more information about the server error messages and exact nfs
> configuration, not sure anyone can help more than this. A common
> problem with Lustre NFS exports, one that isn't due to normal
> NFS/configuration issues, is getting erro
If you replace OFED, you do not need to rebuild the kernel (unless you
want to patch/change it), so you can install the binary Lustre kernel.
You do need to rebuild Lustre (or at least the kernel modules) (step
#3), as o2ib must be built against the OFED you are running.
Kevin
Marco Aurelio
Without more information about the server error messages and exact nfs
configuration, not sure anyone can help more than this. A common
problem with Lustre NFS exports, one that isn't due to normal
NFS/configuration issues, is getting error -43 when the mds did not have
the client's IDs in its
On 2010-07-15, at 15:46, "Adesanya, Adeyemi" wrote:
> We are working on coming up with a backup plan for our Lustre filesystem in
> case we ever lose an OST in the future. I like the idea of backing up the
> filesystem at the client level and then identifying what files were stored on
> a mis
On 2010-07-16, at 0:27, Maxence Dunnewind wrote:
> I just tried on qt4, and it compiles correctly, the results are :
> -j 16 : 30min35 against 32 min
> -j 8 : same time (34min25 vs 34min36)
Thanks for testing this. What it means is that there is very little contention
on the client's single met
My only other suggestion is to dump the Lustre kernel debug log on the NFS
server after a mount failure to see where/why it is getting the permission
error.
# lctl clear
# (mount NFS client)
# lctl dk /tmp/debug
Then search through the logs for -2 errors (-EPERM).
Cheers, Andreas
On 2010-07-
On 7/15/2010 5:48 PM, Andreas Dilger wrote:
> On 2010-07-15, at 08:33, William Olson wrote:
>
>> Somebody, anybody? I'm sure it's something fairly simple, but it
>> escapes me, assistance would be greatly appreciated!
>>
> I can't comment, since my NFS re-exporting (to a MacOS client) is
The use of ext3 or ext4 and the filesystem feature flags has nothing to do with
the setting of the incorrect target. I don't know how you got to that state,
but there are a number of places where the OST index is stored that need to
verified and fixed.
There is the mountdata file, which you ha
>Without size-on-mds, either way would have to query both the mds and
>each OST to get the size info. Not being that familiar with size-on-
>mds, it does seem likely that "du" would still have to query the OST
>for size info, even when "ls -l" does not.
As someone who has spent the past week
On Jul 16, 2010, at 7:17 AM, "Christopher J.Walker" wrote:
> I know Lustre can do quotas per user, but can Lustre do quotas on a
> per
> directory basis?
No, Lustre does not support directory (fileset) based quotas.
> I can't work out how to do this from the manual.
>
> To be more specific,
I didn't find the hack anywhere. I looked at what those files contained and
decided to "hack and slash". Apparently, those files are generated from data
within the filesystem system itself. A second running of writeconf displayed
the target value to be "lustre1-OST", which is what I didn
Does anyone recognise the following logs:
Jul 15 18:24:40 cs04r-sc-mds01-01 kernel: LustreError:
17241:0:(mds_open.c:1053:mds_open()) parent 121938276/854916762
lookup/take lock error -13
Jul 15 18:24:40 cs04r-sc-mds01-01 kernel: LustreError:
17241:0:(mds_open.c:1053:mds_open()) Skipped 5 previ
I know Lustre can do quotas per user, but can Lustre do quotas on a per
directory basis? I can't work out how to do this from the manual.
To be more specific, the software we use[1] is written by people using
GPFS and we'd like an equivalent to the GPFS command:
mmlsquota -j
which AIUI f
21 matches
Mail list logo
