lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 14 Sep 2012 17:51:52 +0900
From:	Namjae Jeon <linkinjeon@...il.com>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	"J. Bruce Fields" <bfields@...ldses.org>,
	"Steven J. Magnani" <steve@...idescorp.com>,
	Al Viro <viro@...iv.linux.org.uk>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org,
	Namjae Jeon <namjae.jeon@...sung.com>,
	Ravishankar N <ravi.n1@...sung.com>,
	Amit Sahrawat <a.sahrawat@...sung.com>
Subject: Re: [PATCH v2 1/5] fat: allocate persistent inode numbers

2012/9/14, OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>:
> "J. Bruce Fields" <bfields@...ldses.org> writes:
>
>>> > Current -mm means the best-effort work only if inode cache is not
>>> > evicted.  I.e. if there is no inode cache anymore on server, server
>>> > would return ESTALE. So I guess the behavior would not be stable
>>> > relatively.
>>> Hi OGAWA.
>>> Sorry for late response.
>>> Okay, I will resend patchset include your suggeston.(-o nfs=2)
>>> Do you mind adding busy list patch to avoid unlink issue ?
>>> And in case of rename, FAT retrun EBUSY while opening file.
>>> We can limit only rename.
>>
>> The server doesn't necessarily know whether a client has the file open,
>> so does that really help?
>
> If you are assuming to do rename() somehow, it would not be true. And if
> so, you might want to rethink about the patch. (btw, I'm not thinking
> deeply yet though, I guess we have to limit unlink() too)
Hi OGAWA.
Sorry, There are some unclear things in unlink solution.
When we tested before, That did really help.
So, we will check unlink solution more and after fully convinced will
send in separate patch later with updates in changelog of patch when
enabling write support..
>
> Well, anyway, I'd like to see stable/clean read-only support at first.
> (with new nfs option, and with MS_RDONLY).  After that, we can
> enable write support.
Okay, I will send stable ino patch(read-only) soon.

Thanks a lot!
> --
> OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ