| 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
| ||
|
Message-ID: <CAKYAXd-k4yVV3h8k0kcFMsyGnOVckYRjXi8fkZrLtjuWVi7Eqw@mail.gmail.com> Date: Mon, 10 Sep 2012 21:03:46 +0900 From: Namjae Jeon <linkinjeon@...il.com> To: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp> Cc: "Steven J. Magnani" <steve@...idescorp.com>, Al Viro <viro@...iv.linux.org.uk>, akpm@...ux-foundation.org, bfields@...ldses.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/9, OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>: > OGAWA Hirofumi <hirofumi@...l.parknet.co.jp> writes: > >> What is your use case? I'm assuming current NFS support of FAT >> is still unstable behavior even with your patches. Is this true? Hi. OGAWA. Yes, It is true(current VFAT of -mm tree is not stable). Although we set lookupcache=none while mounting, ESTALE error can still occur in rename case. So there still remain ESTALE error issue from rename case on current -mm tree. plz See the step as the following 1. on client write to file. 2. on client, move/rename file. 3. on server, do drop_caches. etc to somehow evict indoe number so that it gets new inode number 4. on client, resume the program to write to file. write will fail (write: Stale NFS file handle) ----- As I know, I think that Steve patch tried to fix ESTALE error on best-effort. And Steve said also his patch can perfectly not avoid ESTLE error. And The aim of Steve's patch can be just improved under memory pressure(dentry eviction) on best-effort. ------------------------------------------------------------------------------ Under memory pressure, the system may evict dentries from cache. When the FAT driver receives a NFS request involving an evicted dentry, it is unable to reconnect it to the filesystem root. This causes the request to fail, often with ENOENT. ..... Note that while this patch set improves FAT's NFS support, it does not eliminate ESTALE errors completely. The following should be considered for NFS clients who are sensitive to ESTALE: * Mounting with lookupcache=none Unfortunately this can degrade performance severely, particularly for deep filesystems. * Incorporating VFS patches to retry ESTALE failures on the client-side, such as https://lkml.org/lkml/2012/6/29/381 * Handling ESTALE errors in client application code ------------------------------------------------------------------------------------- And ...... If we mount NFS with lookupcache=none, FAT file lookup performance is severely dropped. LOOKUP performance is very poor on slow network and slow device. I do not recommend to disable lookup cache on NFS. And that is why reconstructing inode is already implemented in other filesystem (e.g. EXT4, XFS etc..) Currently lookupcache is enabled by default in NFS, it means users already have disclosed and experienced ESTALE issues on NFS over VFAT. I agree wth you to make NFS over VFAT read-only filesystem to avoid all issues. Eventually we can make it writable with rename limitation when we decide that it is pretty stable in mainline. So, I suggest to add 'nfs_ro' mount option instead of 'nfs' option. Let me know your opinion. Thanks. > > s/is not unstable/is still unstable/ > -- > 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