ceph vfs

[Sam Lang]

On Wed, Apr 17, 2013 at 2:19 PM, Jeremy Allison <jra at samba.org> wrote:
> On Tue, Apr 16, 2013 at 11:50:53AM -0700, Jeremy Allison wrote:
>> On Tue, Apr 16, 2013 at 10:13:46AM -0700, Jeremy Allison wrote:
>> > On Tue, Apr 16, 2013 at 10:51:13AM -0500, Sam Lang wrote:
>> > > I still have one failing test from smbtorture on the ceph vfs module.
>> > > base.open.ctemp test fails with EPERM.  It looks like reply_ctemp() in
>> > > source3/smbd/reply.c is doing a mkstemp with the path returned by
>> > > realpath, so in the ceph case, its doing:  mkstemp("//TMXXXXXX")
>> > >
>> > > Unsurprisingly, that fails.  On a local filesystem (such as a
>> > > directory like /tmp/foo), realpath resolves the path to
>> > > /tmp/foo/TMXXXXXX.  But with ceph, no separate mountpoint exists
>> > > locally.  How is ctemp meant to be handled by backend vfs modules that
>> > > don't have a separate mount running on the smbd server?
>> >
>> > Oh, you just found a bug in the VFS :-). Thanks !
>> >
>> > reply_ctemp() is a *really* old DOS-style call
>> > that no modern clients do.
>>
>> Just to be clear, there are vendors shipping
>> cloud gateway products that also have no local
>> mounts that have never run into this problem,
>> so it's not an issue in actual customer deployments.
>
> FYI. I have a patch that fixes this issue
> by removing the mkstemp call and using
> only Samba VFS calls.

I can test it on ceph if you want to send it to me.  One of the
patches I posted earlier fixes a minor bug in the ctemp test that
allows smbtorture to continue with the other tests after ctemp has
failed.
-sam

>
> Jeremy.