Re: [PATCH] cifs: fix strcat buffer overflow in smb21_set_oplock_level()

On Mon, May 06, 2019 at 11:53:44AM -0500, Steve French via samba-technical wrote: > I think strcpy is clearer - but I don't think it can overflow since if > R, W or W were written to "message" then cinode->oplock would be > non-zero so we would never strcap "None" Ahem. In Samba we have :

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Mon, Apr 03, 2017 at 11:36:48AM -0700, Jeremy Allison wrote: > On Mon, Apr 03, 2017 at 02:18:44PM -0400, Jeff Layton wrote: > > On Mon, 2017-04-03 at 11:09 -0700, Jeremy Allison wrote: > > > > > > CIFS has a way to reserve space. Look into "allocation size"

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Mon, Apr 03, 2017 at 11:36:48AM -0700, Jeremy Allison wrote: > On Mon, Apr 03, 2017 at 02:18:44PM -0400, Jeff Layton wrote: > > On Mon, 2017-04-03 at 11:09 -0700, Jeremy Allison wrote: > > > > > > CIFS has a way to reserve space. Look into "allocation size"

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Mon, Apr 03, 2017 at 02:18:44PM -0400, Jeff Layton wrote: > On Mon, 2017-04-03 at 11:09 -0700, Jeremy Allison wrote: > > On Mon, Apr 03, 2017 at 01:47:37PM -0400, Jeff Layton wrote: > > > On Mon, 2017-04-03 at 07:32 -0700, Matthew Wilcox wrote: > > > > On Mon, Ap

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Mon, Apr 03, 2017 at 02:18:44PM -0400, Jeff Layton wrote: > On Mon, 2017-04-03 at 11:09 -0700, Jeremy Allison wrote: > > On Mon, Apr 03, 2017 at 01:47:37PM -0400, Jeff Layton wrote: > > > On Mon, 2017-04-03 at 07:32 -0700, Matthew Wilcox wrote: > > > > On Mon, Ap

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Mon, Apr 03, 2017 at 01:47:37PM -0400, Jeff Layton wrote: > On Mon, 2017-04-03 at 07:32 -0700, Matthew Wilcox wrote: > > On Mon, Apr 03, 2017 at 06:28:38AM -0400, Jeff Layton wrote: > > > On Mon, 2017-04-03 at 14:25 +1000, NeilBrown wrote: > > > > Also I think that EIO should always over-ride

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Mon, Apr 03, 2017 at 01:47:37PM -0400, Jeff Layton wrote: > On Mon, 2017-04-03 at 07:32 -0700, Matthew Wilcox wrote: > > On Mon, Apr 03, 2017 at 06:28:38AM -0400, Jeff Layton wrote: > > > On Mon, 2017-04-03 at 14:25 +1000, NeilBrown wrote: > > > > Also I think that EIO should always over-ride

Re: [PATCH v27 03/21] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags

On Tue, Dec 06, 2016 at 10:25:22PM +0100, Miklos Szeredi wrote: > On Tue, Dec 6, 2016 at 10:13 PM, Jeremy Allison <j...@samba.org> wrote: > > On Tue, Dec 06, 2016 at 03:15:29PM -0500, J. Bruce Fields wrote: > >> On Fri, Dec 02, 2016 at 10:57:42AM +0100, Miklos Szeredi wrot

Re: [PATCH v27 03/21] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags

On Tue, Dec 06, 2016 at 10:25:22PM +0100, Miklos Szeredi wrote: > On Tue, Dec 6, 2016 at 10:13 PM, Jeremy Allison wrote: > > On Tue, Dec 06, 2016 at 03:15:29PM -0500, J. Bruce Fields wrote: > >> On Fri, Dec 02, 2016 at 10:57:42AM +0100, Miklos Szeredi wrote: > >> > O

Re: [PATCH v27 03/21] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags

On Tue, Dec 06, 2016 at 03:15:29PM -0500, J. Bruce Fields wrote: > On Fri, Dec 02, 2016 at 10:57:42AM +0100, Miklos Szeredi wrote: > > On Tue, Oct 11, 2016 at 2:50 PM, Andreas Gruenbacher > > wrote: > > > Normally, deleting a file requires MAY_WRITE access to the parent > > >

Re: [PATCH v27 03/21] vfs: Add MAY_DELETE_SELF and MAY_DELETE_CHILD permission flags

On Tue, Dec 06, 2016 at 03:15:29PM -0500, J. Bruce Fields wrote: > On Fri, Dec 02, 2016 at 10:57:42AM +0100, Miklos Szeredi wrote: > > On Tue, Oct 11, 2016 at 2:50 PM, Andreas Gruenbacher > > wrote: > > > Normally, deleting a file requires MAY_WRITE access to the parent > > > directory. With

Re: [PATCH v21 00/22] Richacls

On Tue, May 10, 2016 at 06:18:10AM +0200, Volker Lendecke wrote: > On Tue, May 10, 2016 at 12:02:33AM +0200, Andreas Gruenbacher wrote: > > What more can I do to finally get this merged? > > While I am not the one to comment on kernel specifics, from a pure Samba > user space perspective let me

Re: [PATCH v21 00/22] Richacls

On Tue, May 10, 2016 at 06:18:10AM +0200, Volker Lendecke wrote: > On Tue, May 10, 2016 at 12:02:33AM +0200, Andreas Gruenbacher wrote: > > What more can I do to finally get this merged? > > While I am not the one to comment on kernel specifics, from a pure Samba > user space perspective let me

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

On Tue, Mar 15, 2016 at 12:11:03AM -0700, Christoph Hellwig wrote: > On Fri, Mar 11, 2016 at 05:11:51PM +0100, Andreas Gruenbacher wrote: > > > while breaking a lot of assumptions, > > > > The model is designed specifically to be compliant with the POSIX > > permission model. What assumptions are

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

On Tue, Mar 15, 2016 at 12:11:03AM -0700, Christoph Hellwig wrote: > On Fri, Mar 11, 2016 at 05:11:51PM +0100, Andreas Gruenbacher wrote: > > > while breaking a lot of assumptions, > > > > The model is designed specifically to be compliant with the POSIX > > permission model. What assumptions are

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

On Mon, Mar 14, 2016 at 12:02:13AM +0100, Andreas Gruenbacher wrote: > On Sat, Mar 12, 2016 at 12:02 AM, Jeremy Allison <j...@samba.org> wrote: > > On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote: > >> Sounds like I need to quickly rework the SMB3 ACL helper fu

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

On Mon, Mar 14, 2016 at 12:02:13AM +0100, Andreas Gruenbacher wrote: > On Sat, Mar 12, 2016 at 12:02 AM, Jeremy Allison wrote: > > On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote: > >> Sounds like I need to quickly rework the SMB3 ACL helper functions > >>

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote: > Sounds like I need to quickly rework the SMB3 ACL helper functions > for cifs.ko > > Also do you know where is the current version of the corresponding > vfs_richacl for > Samba which works with the current RichACL format? I have a

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote: > Sounds like I need to quickly rework the SMB3 ACL helper functions > for cifs.ko > > Also do you know where is the current version of the corresponding > vfs_richacl for > Samba which works with the current RichACL format? I have a

Re: [RFC v3 00/45] Richacls

On Fri, Apr 24, 2015 at 01:03:57PM +0200, Andreas Gruenbacher wrote: > Hello, > > here's another update of the richacl patch queue. The changes since the last > posting (https://lwn.net/Articles/638242/) include: > > * The nfs client now allocates pages for received acls on demand like the >

Re: [RFC v3 00/45] Richacls

On Fri, Apr 24, 2015 at 01:03:57PM +0200, Andreas Gruenbacher wrote: Hello, here's another update of the richacl patch queue. The changes since the last posting (https://lwn.net/Articles/638242/) include: * The nfs client now allocates pages for received acls on demand like the

Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks

On Thu, May 14, 2015 at 04:24:13PM -0700, Linus Torvalds wrote: > On Thu, May 14, 2015 at 3:09 PM, Jeremy Allison wrote: > > > > Of course we tell people to just set their filesystems > > up using mkfs.xfs -n version=ci :-). > > So ASCII-only case-insensitivity

Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks

On Wed, May 13, 2015 at 08:52:59PM -0700, Linus Torvalds wrote: > On Wed, May 13, 2015 at 8:30 PM, Al Viro wrote: > > > > Maybe... I'd like to see the profiles, TBH - especially getxattr() and > > access() frequency on various loads. Sure, make(1) and cc(1) really care > > about stat() very

Re: [RFC][PATCHSET v3] non-recursive pathname resolution RCU symlinks

On Wed, May 13, 2015 at 08:52:59PM -0700, Linus Torvalds wrote: On Wed, May 13, 2015 at 8:30 PM, Al Viro v...@zeniv.linux.org.uk wrote: Maybe... I'd like to see the profiles, TBH - especially getxattr() and access() frequency on various loads. Sure, make(1) and cc(1) really care about

Re: [RFC][PATCHSET v3] non-recursive pathname resolution RCU symlinks

On Thu, May 14, 2015 at 04:24:13PM -0700, Linus Torvalds wrote: On Thu, May 14, 2015 at 3:09 PM, Jeremy Allison j...@samba.org wrote: Of course we tell people to just set their filesystems up using mkfs.xfs -n version=ci :-). So ASCII-only case-insensitivity is sufficient for you guys

Re: [RFC v3 20/45] richacl: Automatic Inheritance

On Wed, May 13, 2015 at 10:47:44PM +0200, Andreas Grünbacher wrote: > 2015-05-13 22:28 GMT+02:00 Jeremy Allison : > > On Wed, May 13, 2015 at 10:22:21PM +0200, Andreas Grünbacher wrote: > >> > >> That being said, a daemon like Samba can "fake" full Automat

Re: [RFC v3 20/45] richacl: Automatic Inheritance

On Wed, May 13, 2015 at 10:22:21PM +0200, Andreas Grünbacher wrote: > > That being said, a daemon like Samba can "fake" full Automatic > Inheritance by creating files and then updating the inherited acls > appropriately. This will inevitably be racy, but unless someone > implements a way to

Re: xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?)

On Wed, May 13, 2015 at 12:37:41PM -0700, Daniel Phillips wrote: > On 05/13/2015 12:09 PM, Martin Steigerwald wrote: > > > "Assume good faith" can help here. No amount of accusing people of bad > > intention will change them. The only thing you have the power to change is > > your approach. You

Re: [RFC v3 20/45] richacl: Automatic Inheritance

On Wed, May 13, 2015 at 10:47:44PM +0200, Andreas Grünbacher wrote: 2015-05-13 22:28 GMT+02:00 Jeremy Allison j...@samba.org: On Wed, May 13, 2015 at 10:22:21PM +0200, Andreas Grünbacher wrote: That being said, a daemon like Samba can fake full Automatic Inheritance by creating files

Re: xfs: does mkfs.xfs require fancy switches to get decent performance? (was Tux3 Report: How fast can we fsync?)

On Wed, May 13, 2015 at 12:37:41PM -0700, Daniel Phillips wrote: On 05/13/2015 12:09 PM, Martin Steigerwald wrote: Assume good faith can help here. No amount of accusing people of bad intention will change them. The only thing you have the power to change is your approach. You

Re: [RFC v3 20/45] richacl: Automatic Inheritance

On Wed, May 13, 2015 at 10:22:21PM +0200, Andreas Grünbacher wrote: That being said, a daemon like Samba can fake full Automatic Inheritance by creating files and then updating the inherited acls appropriately. This will inevitably be racy, but unless someone implements a way to create files

Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)

On Mon, Mar 30, 2015 at 01:37:58PM -0700, Andrew Morton wrote: > On Mon, 30 Mar 2015 13:32:27 -0700 Jeremy Allison wrote: > > > On Mon, Mar 30, 2015 at 01:26:25PM -0700, Andrew Morton wrote: > > > > > > cons: > > > > > > d) fincore() is mo

Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)

On Mon, Mar 30, 2015 at 01:26:25PM -0700, Andrew Morton wrote: > > cons: > > d) fincore() is more expensive > > e) fincore() will very occasionally block The above is the killer for Samba. If fincore returns true but when we schedule the pread we block, we're hosed. Once we block, we're done

Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)

On Mon, Mar 30, 2015 at 12:36:04AM -0700, Christoph Hellwig wrote: > On Fri, Mar 27, 2015 at 08:58:54AM -0700, Jeremy Allison wrote: > > The problem with the above is that we can't tell the difference > > between pread2() returning a short read because the pages are not > >

Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)

On Mon, Mar 30, 2015 at 12:36:04AM -0700, Christoph Hellwig wrote: On Fri, Mar 27, 2015 at 08:58:54AM -0700, Jeremy Allison wrote: The problem with the above is that we can't tell the difference between pread2() returning a short read because the pages are not in cache, or because someone

Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)

On Mon, Mar 30, 2015 at 01:26:25PM -0700, Andrew Morton wrote: cons: d) fincore() is more expensive e) fincore() will very occasionally block The above is the killer for Samba. If fincore returns true but when we schedule the pread we block, we're hosed. Once we block, we're done

Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)

On Mon, Mar 30, 2015 at 01:37:58PM -0700, Andrew Morton wrote: On Mon, 30 Mar 2015 13:32:27 -0700 Jeremy Allison j...@samba.org wrote: On Mon, Mar 30, 2015 at 01:26:25PM -0700, Andrew Morton wrote: cons: d) fincore() is more expensive e) fincore() will very occasionally

Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)

On Fri, Mar 27, 2015 at 09:30:46AM -0700, Andrew Morton wrote: > > But from an interface perspective the behaviour you're asking for is > insane, frankly - if the kernel copied out 8k of data then pread2() > should return 8k. Otherwise there's no way for userspace to know that > the 8k copy

Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)

On Fri, Mar 27, 2015 at 02:01:59AM -0700, Andrew Morton wrote: > On Fri, 27 Mar 2015 01:48:33 -0700 Christoph Hellwig > wrote: > > > On Fri, Mar 27, 2015 at 01:35:16AM -0700, Andrew Morton wrote: > > > fincore() doesn't have to be ugly. Please address the design issues I > > > raised. How is

Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)

On Fri, Mar 27, 2015 at 09:30:46AM -0700, Andrew Morton wrote: But from an interface perspective the behaviour you're asking for is insane, frankly - if the kernel copied out 8k of data then pread2() should return 8k. Otherwise there's no way for userspace to know that the 8k copy actually

Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)

On Fri, Mar 27, 2015 at 02:01:59AM -0700, Andrew Morton wrote: On Fri, 27 Mar 2015 01:48:33 -0700 Christoph Hellwig h...@infradead.org wrote: On Fri, Mar 27, 2015 at 01:35:16AM -0700, Andrew Morton wrote: fincore() doesn't have to be ugly. Please address the design issues I raised.

Re: [PATCH v12 00/20] DAX: Page cache bypass for filesystems on memory storage

On Thu, Jan 08, 2015 at 11:28:40AM -0500, Milosz Tanski wrote: > > > > Andrew I got busier with my other job related things between the > Thanksgiving & Christmas then anticipated. However, I have updated and > taken apart the patchset into two pieces (preadv2 and pwritev2). That > should make

Re: [PATCH v12 00/20] DAX: Page cache bypass for filesystems on memory storage

On Thu, Jan 08, 2015 at 11:28:40AM -0500, Milosz Tanski wrote: Andrew I got busier with my other job related things between the Thanksgiving Christmas then anticipated. However, I have updated and taken apart the patchset into two pieces (preadv2 and pwritev2). That should make

Re: [RFC PATCH] fs: allow open(dir, O_TMPFILE|..., 0) with mode 0

On Mon, Nov 03, 2014 at 10:49:24AM -0800, Eric Rannaud wrote: > On Mon, Nov 3, 2014 at 9:06 AM, Andy Lutomirski wrote: > >> That doesn't help because we explicitly reject O_RDONLY when combined > >> with O_TMPFILE. > > > > I think I'm missing something. How is an O_RDONLY temporary file > >

Re: [RFC PATCH] fs: allow open(dir, O_TMPFILE|..., 0) with mode 0

On Mon, Nov 03, 2014 at 10:49:24AM -0800, Eric Rannaud wrote: On Mon, Nov 3, 2014 at 9:06 AM, Andy Lutomirski l...@amacapital.net wrote: That doesn't help because we explicitly reject O_RDONLY when combined with O_TMPFILE. I think I'm missing something. How is an O_RDONLY temporary file

Re: should we change the name/macros of file-private locks?

On Wed, Apr 16, 2014 at 10:00:46PM +0200, Michael Kerrisk (man-pages) wrote: > [CC += Jeremy Allison] > > On Wed, Apr 16, 2014 at 8:57 PM, Jeff Layton wrote: > > Sorry to spam so many lists, but I think this needs widespread > > distribution and consensus. > > >

Re: should we change the name/macros of file-private locks?

On Wed, Apr 16, 2014 at 10:00:46PM +0200, Michael Kerrisk (man-pages) wrote: [CC += Jeremy Allison] On Wed, Apr 16, 2014 at 8:57 PM, Jeff Layton jlay...@redhat.com wrote: Sorry to spam so many lists, but I think this needs widespread distribution and consensus. File-private locks have

Re: Thoughts on credential switching

On Mon, Mar 31, 2014 at 11:44:59AM +0100, One Thousand Gnomes wrote: > On Wed, 26 Mar 2014 17:23:24 -0700 > Andy Lutomirski wrote: > > > Hi various people who care about user-space NFS servers and/or > > security-relevant APIs. > > > > I propose the following set of new syscalls: > > > > int

Re: Thoughts on credential switching

On Mon, Mar 31, 2014 at 11:44:59AM +0100, One Thousand Gnomes wrote: On Wed, 26 Mar 2014 17:23:24 -0700 Andy Lutomirski l...@amacapital.net wrote: Hi various people who care about user-space NFS servers and/or security-relevant APIs. I propose the following set of new syscalls:

Re: Thoughts on credential switching

On Thu, Mar 27, 2014 at 11:46:39AM -0700, Andy Lutomirski wrote: > On Thu, Mar 27, 2014 at 11:26 AM, Jeremy Allison wrote: > > > > Amen to that :-). > > > > However, after talking with Jeff and Jim at CollabSummit, > > I was 'encouraged' to make my opinions

Re: Thoughts on credential switching

On Thu, Mar 27, 2014 at 07:01:26AM -0700, Jeff Layton wrote: > On Thu, 27 Mar 2014 14:06:32 +0100 > Florian Weimer wrote: > > > On 03/27/2014 02:02 PM, Jeff Layton wrote: > > > > >> This interface does not address the long-term lack of POSIX > > >> compliance in setuid and friends, which are

Re: Thoughts on credential switching

On Thu, Mar 27, 2014 at 07:01:26AM -0700, Jeff Layton wrote: On Thu, 27 Mar 2014 14:06:32 +0100 Florian Weimer fwei...@redhat.com wrote: On 03/27/2014 02:02 PM, Jeff Layton wrote: This interface does not address the long-term lack of POSIX compliance in setuid and friends, which are

Re: Thoughts on credential switching

On Thu, Mar 27, 2014 at 11:46:39AM -0700, Andy Lutomirski wrote: On Thu, Mar 27, 2014 at 11:26 AM, Jeremy Allison j...@samba.org wrote: Amen to that :-). However, after talking with Jeff and Jim at CollabSummit, I was 'encouraged' to make my opinions known on the list. To me

Re: [PATCH v2] ceph: fix posix ACL hooks

On Mon, Feb 03, 2014 at 10:31:27PM +, Al Viro wrote: > > > And the fact is, filesystems with hardlinks and path-name-based > > operations do exist. cifs with the unix extensions is one of them. > > Pox on Tridge... Actually you have to blame me for that. Tridge always *HATED* the UNIX

Re: [PATCH v2] ceph: fix posix ACL hooks

On Mon, Feb 03, 2014 at 10:31:27PM +, Al Viro wrote: And the fact is, filesystems with hardlinks and path-name-based operations do exist. cifs with the unix extensions is one of them. Pox on Tridge... Actually you have to blame me for that. Tridge always *HATED* the UNIX extensions

Re: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks

On Fri, 11 Oct 2013 15:36:43 -0600 Andreas Dilger wrote: > > > > At this point, my main questions are: > > > > 1) does this look useful, particularly for fileserver implementors? Yes from the Samba perspective. We'll have to keep the old code around for compatibility with non-Linux OS'es, but

Re: [RFC PATCH 0/5] locks: implement filp-private (aka UNPOSIX) locks

On Fri, 11 Oct 2013 15:36:43 -0600 Andreas Dilger adil...@dilger.ca wrote: At this point, my main questions are: 1) does this look useful, particularly for fileserver implementors? Yes from the Samba perspective. We'll have to keep the old code around for compatibility with non-Linux

Re: Recvfile patch used for Samba.

On Tue, Jul 23, 2013 at 05:10:27PM +1000, Dave Chinner wrote: > So, we are nesting up to 32 page locks here. That's bad. And we are > nesting kmap() calls for all the pages individually - is that even > safe to do? > > So, what happens when we've got 16 pages in, and the filesystem has >

Re: Recvfile patch used for Samba.

On Tue, Jul 23, 2013 at 05:10:27PM +1000, Dave Chinner wrote: So, we are nesting up to 32 page locks here. That's bad. And we are nesting kmap() calls for all the pages individually - is that even safe to do? So, what happens when we've got 16 pages in, and the filesystem has allocated

Recvfile patch used for Samba.

Hi Steve and Jeff (and others). Here is a patch that Samba vendors have been using to implement recvfile (copy directly from socket to file). It can improve write performance on boxes by a significant amount (10% or more). I'm not qualified to evaluate this code, can someone who is (hi there

Recvfile patch used for Samba.

Hi Steve and Jeff (and others). Here is a patch that Samba vendors have been using to implement recvfile (copy directly from socket to file). It can improve write performance on boxes by a significant amount (10% or more). I'm not qualified to evaluate this code, can someone who is (hi there

Re: New copyfile system call - discuss before LSF?

On Thu, Feb 21, 2013 at 01:51:53PM +, Myklebust, Trond wrote: > On Thu, 2013-02-21 at 12:37 +0100, Ric Wheeler wrote: > > We have debated the need to have a system call to allow for offloading copy > > operations, for example to an NFS server (part to the new NFS 4.2 > > specification), SCSI

Re: New copyfile system call - discuss before LSF?

On Thu, Feb 21, 2013 at 01:51:53PM +, Myklebust, Trond wrote: On Thu, 2013-02-21 at 12:37 +0100, Ric Wheeler wrote: We have debated the need to have a system call to allow for offloading copy operations, for example to an NFS server (part to the new NFS 4.2 specification), SCSI target

Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs

On Thu, Dec 06, 2012 at 04:37:27PM -0500, Theodore Ts'o wrote: > On Thu, Dec 06, 2012 at 01:33:29PM -0800, Jeremy Allison wrote: > > > I'm confused; why would a userspace application need to be able to > > > request this behavior? > > > > This isn't my

Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs

On Thu, Dec 06, 2012 at 04:31:33PM -0500, Theodore Ts'o wrote: > On Thu, Dec 06, 2012 at 11:57:52AM -0800, Jeremy Allison wrote: > > > > And this is where things get really ugly of course :-). > > > > For the CIFSFS client they're expecting to be able to > > j

Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs

On Thu, Dec 06, 2012 at 11:57:52AM -0800, Jeremy Allison wrote: > On Thu, Dec 06, 2012 at 07:49:49PM +, Alan Cox wrote: > > On Thu, 6 Dec 2012 22:26:28 +0400 > > Pavel Shilovsky wrote: > > > > > Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such

Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs

On Thu, Dec 06, 2012 at 07:49:49PM +, Alan Cox wrote: > On Thu, 6 Dec 2012 22:26:28 +0400 > Pavel Shilovsky wrote: > > > Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this > > change can benefit cifs and nfs modules. While this change is ok for > > network

Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs

On Thu, Dec 06, 2012 at 07:49:49PM +, Alan Cox wrote: On Thu, 6 Dec 2012 22:26:28 +0400 Pavel Shilovsky pias...@etersoft.ru wrote: Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this change can benefit cifs and nfs modules. While this change is ok for network

Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs

On Thu, Dec 06, 2012 at 11:57:52AM -0800, Jeremy Allison wrote: On Thu, Dec 06, 2012 at 07:49:49PM +, Alan Cox wrote: On Thu, 6 Dec 2012 22:26:28 +0400 Pavel Shilovsky pias...@etersoft.ru wrote: Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this change

Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs

On Thu, Dec 06, 2012 at 04:31:33PM -0500, Theodore Ts'o wrote: On Thu, Dec 06, 2012 at 11:57:52AM -0800, Jeremy Allison wrote: And this is where things get really ugly of course :-). For the CIFSFS client they're expecting to be able to just ship them to a Windows server, where

Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs

On Thu, Dec 06, 2012 at 04:37:27PM -0500, Theodore Ts'o wrote: On Thu, Dec 06, 2012 at 01:33:29PM -0800, Jeremy Allison wrote: I'm confused; why would a userspace application need to be able to request this behavior? This isn't my proposal Ted, I'm just commenting on it :-). Ah

Re: Versioning file system

On Tue, Jun 19, 2007 at 03:05:07AM -0400, Theodore Tso wrote: > > There is a partial implementation lieing around somewhere, but there > were a number of problems we ran into that were discussed in the > slidedeck. Basically, if the only program accessing the files > containing forks was the

Re: Versioning file system

On Tue, Jun 19, 2007 at 03:05:07AM -0400, Theodore Tso wrote: There is a partial implementation lieing around somewhere, but there were a number of problems we ran into that were discussed in the slidedeck. Basically, if the only program accessing the files containing forks was the Samba

Re: Versioning file system

On Mon, Jun 18, 2007 at 06:10:21PM -0400, Theodore Tso wrote: > On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote: > > And that makes them different from extended attributes, how? > > > > Both of these really are nothing but ad hocky syntactic sugar for > > directories, sometimes

Re: Versioning file system

On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote: > > Pointless here means that _I_ don't see the point. Maybe there are > valid uses for extended attributes. If there are, noone has explained > them to me yet. Samba uses them to store DOS'ism's that you don't want in your POSIX

Re: Versioning file system

On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote: > And that makes them different from extended attributes, how? Streams on systems that support them allow lseek and are accessed by fd's. EA's are always a blob of data, read/written in their entirity. Jeremy. - To unsubscribe from

Re: Versioning file system

On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote: > On Mon, Jun 18, 2007 at 09:16:30AM -0700, alan wrote: > > > > I just wish that people would learn from the mistakes of others. The > > MacOS is a prime example of why you do not want to use a forked > > filesystem, yet some people

Re: Versioning file system

On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote: On Mon, Jun 18, 2007 at 09:16:30AM -0700, alan wrote: I just wish that people would learn from the mistakes of others. The MacOS is a prime example of why you do not want to use a forked filesystem, yet some people still

Re: Versioning file system

On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote: And that makes them different from extended attributes, how? Streams on systems that support them allow lseek and are accessed by fd's. EA's are always a blob of data, read/written in their entirity. Jeremy. - To unsubscribe from

Re: Versioning file system

On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote: Pointless here means that _I_ don't see the point. Maybe there are valid uses for extended attributes. If there are, noone has explained them to me yet. Samba uses them to store DOS'ism's that you don't want in your POSIX

Re: Versioning file system

On Mon, Jun 18, 2007 at 06:10:21PM -0400, Theodore Tso wrote: On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote: And that makes them different from extended attributes, how? Both of these really are nothing but ad hocky syntactic sugar for directories, sometimes combined

Re: [linux-cifs-client] Re: SMB2 file system - should it be a distinct module

On Thu, May 03, 2007 at 09:46:05AM -0500, Gerald Carter wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Simo, > > > I guess DFS referrals can work cross protocol, so if you are redirected > > from a longhorn server to a windoes 2000 or a samba server you want to > > be able to

Re: [linux-cifs-client] Re: SMB2 file system - should it be a distinct module

On Thu, May 03, 2007 at 09:46:05AM -0500, Gerald Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simo, I guess DFS referrals can work cross protocol, so if you are redirected from a longhorn server to a windoes 2000 or a samba server you want to be able to follow the DFS

Re: Ext3 vs NTFS performance

On Wed, May 02, 2007 at 12:16:38PM -0400, Theodore Tso wrote: > On Tue, May 01, 2007 at 02:23:25PM -0700, Andrew Morton wrote: > > On Tue, 1 May 2007 13:43:18 -0700 > > "Cabot, Mason B" <[EMAIL PROTECTED]> wrote: > > > > > I've been testing the NAS performance of ext3/Openfiler 2.2 against > > >

Re: Ext3 vs NTFS performance

On Wed, May 02, 2007 at 12:16:38PM -0400, Theodore Tso wrote: On Tue, May 01, 2007 at 02:23:25PM -0700, Andrew Morton wrote: On Tue, 1 May 2007 13:43:18 -0700 Cabot, Mason B [EMAIL PROTECTED] wrote: I've been testing the NAS performance of ext3/Openfiler 2.2 against NTFS/WinXP and

Re: [linux-cifs-client] Re: cifs and kthread_run / kernel_thread

On Tue, Apr 03, 2007 at 02:17:59PM -0500, Steve French wrote: > Now merged into cifs-2.6 git tree. Thanks to Q and Wilhelm Up to date SVN please ! :-). Jeremy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo

Re: [linux-cifs-client] Re: cifs and kthread_run / kernel_thread

On Tue, Apr 03, 2007 at 02:17:59PM -0500, Steve French wrote: Now merged into cifs-2.6 git tree. Thanks to Q and Wilhelm Up to date SVN please ! :-). Jeremy. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo

Re: [RFC] Heads up on sys_fallocate()

On Thu, Mar 01, 2007 at 03:23:19PM -0500, Jeff Garzik wrote: > I certainly agree that we want something like this. > > posix_fallocate() is the glibc interface we want to be compatible with > (which your definition is, AFAICS). This would be great for Samba. Windows clients do this a lot

Re: [RFC] Heads up on sys_fallocate()

On Thu, Mar 01, 2007 at 03:23:19PM -0500, Jeff Garzik wrote: I certainly agree that we want something like this. posix_fallocate() is the glibc interface we want to be compatible with (which your definition is, AFAICS). This would be great for Samba. Windows clients do this a lot

Re: Status Of POSIX ACLs

wait for the next kernel-traffic summary and take my answer off line (in the grand tradition of polite radio talk show call in listeners :-). Cheers, Jeremy Allison, Samba Team. -- Buying an operating system without source is l

Re: Status Of POSIX ACLs

wait for the next kernel-traffic summary and take my answer off line (in the grand tradition of polite radio talk show call in listeners :-). Cheers, Jeremy Allison, Samba Team. -- Buying an operating system without source is l