On Wed, Mar 19, 2014 at 02:57:06PM +0100, Miklos Szeredi wrote:
> Hi Dave,
>
> On Mon, Feb 17, 2014 at 07:19:11PM +1100, Dave Chinner wrote:
> > On Wed, Feb 12, 2014 at 06:18:52PM +0100, Miklos Szeredi wrote:
> > > On Tue, Feb 11, 2014 at 05:01:41PM +0100, Miklos Szeredi wrote:
> > > > On Mon, Feb
Hi Dave,
On Mon, Feb 17, 2014 at 07:19:11PM +1100, Dave Chinner wrote:
> On Wed, Feb 12, 2014 at 06:18:52PM +0100, Miklos Szeredi wrote:
> > On Tue, Feb 11, 2014 at 05:01:41PM +0100, Miklos Szeredi wrote:
> > > On Mon, Feb 10, 2014 at 09:51:45PM +1100, Dave Chinner wrote:
> >
> > > > Miklos, can
On Mon 24-02-14 18:12:38, Miklos Szeredi wrote:
> On Thu, Feb 13, 2014 at 09:28:50PM +0100, Miklos Szeredi wrote:
> > On Thu, Feb 13, 2014 at 8:32 PM, Linus Torvalds
> > wrote:
>
> > > (I do think we should allow creation - but for root only - for
> > > management and testing purposes, but I real
Miklos Szeredi:
> As Linus' suggestion, a whiteout is represented as a dummy char device.
> This patch uses the 0/0 device number, but the actual number doesn't matter
> as long as it doesn't conflict with a real device.
I have no objection about the char device.
But why do we need an inode for e
On Mon, Feb 24, 2014 at 9:12 AM, Miklos Szeredi wrote:
>
> This patch uses the 0/0 device number, but the actual number doesn't matter
> as long as it doesn't conflict with a real device.
Side note: I think 0/0 is the right choice, for a very specific
reason: it is already documented as being spe
On Thu, Feb 13, 2014 at 09:28:50PM +0100, Miklos Szeredi wrote:
> On Thu, Feb 13, 2014 at 8:32 PM, Linus Torvalds
> wrote:
> > (I do think we should allow creation - but for root only - for
> > management and testing purposes, but I really think it's a secondary
> > issue, and I do think we shoul
On Mon, Feb 17, 2014 at 07:19:11PM +1100, Dave Chinner wrote:
> [ FWIW, the normal way to write an xfstest like this is to write a
> small helper program that just does the renameat2() syscall (we
> often use xfs_io to provide this) and everything is just shell
> scripts to drive the helper program
On Wed, Feb 12, 2014 at 06:18:52PM +0100, Miklos Szeredi wrote:
> On Tue, Feb 11, 2014 at 05:01:41PM +0100, Miklos Szeredi wrote:
> > On Mon, Feb 10, 2014 at 09:51:45PM +1100, Dave Chinner wrote:
>
> > > Miklos, can you please write an xfstest for this new API? That way
> > > we can verify that th
On Thu, Feb 13, 2014 at 8:32 PM, Linus Torvalds
wrote:
> On Thu, Feb 13, 2014 at 11:02 AM, David Howells wrote:
>>
>> Whilst that does seem reasonable, what about all the other software that
>> iterates over a directory? Some of that is surely not going to know about
>> DT_WHT.
>
> So?
>
> Remeb
Linus Torvalds writes:
> On Thu, Feb 13, 2014 at 11:02 AM, David Howells wrote:
>>
>> Whilst that does seem reasonable, what about all the other software that
>> iterates over a directory? Some of that is surely not going to know about
>> DT_WHT.
>
> So?
>
> Remeber: whiteout entries do not exi
On Thu, Feb 13, 2014 at 11:02 AM, David Howells wrote:
>
> Whilst that does seem reasonable, what about all the other software that
> iterates over a directory? Some of that is surely not going to know about
> DT_WHT.
So?
Remeber: whiteout entries do not exist "normally". No normal apps
should
On Tue, Feb 11, 2014 at 04:57:44PM +0100, Miklos Szeredi wrote:
> On Fri, Feb 07, 2014 at 05:46:30PM -0500, J. Bruce Fields wrote:
>
> > > Bruce, could you please review the locking and delegation thing in patch
> > > #8
> > > "vfs: add cross-rename"?
> >
> > Yep, done. I'll also try running th
On Thu, Feb 13, 2014 at 10:56 AM, Miklos Szeredi wrote:
>
> Fair enough, that allows the thing to be listed, at least.
>
> What about creation? A new syscall?
>
> Removal? unlink(2)?
>
> Should stat(2) succeed with a new filetype?
I think it had better work exactly like a special node (eg chara
Linus Torvalds wrote:
> So what do others that support this do? Looking at the gitweb for
> ls.c in coreutils, we find:
>
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/ls.c
>
> # ifdef DT_WHT
> case DT_WHT: type = whiteout; break;
> #
On Thu, Feb 13, 2014 at 7:29 PM, Linus Torvalds
wrote:
> On Thu, Feb 13, 2014 at 9:28 AM, Miklos Szeredi wrote:
>>>
>>> I would suggest that whiteouts appear as otherwise negative dentries and
>>> that
>>> they don't appear in getdents().
>>
>> I'd argue that this is an administration nightmare.
On Thu, Feb 13, 2014 at 9:28 AM, Miklos Szeredi wrote:
>>
>> I would suggest that whiteouts appear as otherwise negative dentries and that
>> they don't appear in getdents().
>
> I'd argue that this is an administration nightmare. E.g. what if the
> a backup needs to be made of the rw layer?
The
On Thu, Feb 13, 2014 at 9:28 AM, Miklos Szeredi wrote:
> On Thu, Feb 13, 2014 at 5:42 PM, David Howells wrote:
>> Miklos Szeredi wrote:
>>
>>> Regarding whiteouts, I raised a couple of questions that nobody answered
>>> yet, so let me ask again.
>>>
>>> - If a filesystem containing whiteouts (fa
On Thu, Feb 13, 2014 at 5:42 PM, David Howells wrote:
> Miklos Szeredi wrote:
>
>> Regarding whiteouts, I raised a couple of questions that nobody answered
>> yet, so let me ask again.
>>
>> - If a filesystem containing whiteouts (fallthroughs, etc...) is mounted as
>> not part of a union, how
Miklos Szeredi wrote:
> Regarding whiteouts, I raised a couple of questions that nobody answered
> yet, so let me ask again.
>
> - If a filesystem containing whiteouts (fallthroughs, etc...) is mounted as
> not part of a union, how are these special entities represented to
> userspace?
I wo
On Thu, Feb 13, 2014 at 03:54:14PM +, David Howells wrote:
>
> If we're going to be adding a new rename inode op, can we make it take a flag
> to white out the source for union type things? This would mean that
> rename-and-white-out can be done atomically.
That is an option, yes.
Regarding
If we're going to be adding a new rename inode op, can we make it take a flag
to white out the source for union type things? This would mean that
rename-and-white-out can be done atomically.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Tue, Feb 11, 2014 at 05:01:41PM +0100, Miklos Szeredi wrote:
> On Mon, Feb 10, 2014 at 09:51:45PM +1100, Dave Chinner wrote:
> > Miklos, can you please write an xfstest for this new API? That way
> > we can verify that the behaviour is as documented, and we can ensure
> > that when we implement
On Mon, Feb 10, 2014 at 09:51:45PM +1100, Dave Chinner wrote:
> On Fri, Feb 07, 2014 at 05:48:58PM +0100, Miklos Szeredi wrote:
> > Changes since the last version (based on Al's review):
> >
> > - cross-rename: fix locking of nondirectories for NFSv4
> > - ext4: split cross-rename and plain rena
On Fri, Feb 07, 2014 at 05:46:30PM -0500, J. Bruce Fields wrote:
> > Bruce, could you please review the locking and delegation thing in patch #8
> > "vfs: add cross-rename"?
>
> Yep, done. I'll also try running this through my nfs tests, for what
> it's worth. (Not today as there's some unrelat
On Fri, Feb 07, 2014 at 05:48:58PM +0100, Miklos Szeredi wrote:
> Changes since the last version (based on Al's review):
>
> - cross-rename: fix locking of nondirectories for NFSv4
> - ext4: split cross-rename and plain rename into separate functions
> - introduce i_op->rename2 with flags, don'
On Fri, Feb 07, 2014 at 05:48:58PM +0100, Miklos Szeredi wrote:
> Changes since the last version (based on Al's review):
>
> - cross-rename: fix locking of nondirectories for NFSv4
> - ext4: split cross-rename and plain rename into separate functions
> - introduce i_op->rename2 with flags, don'
Changes since the last version (based on Al's review):
- cross-rename: fix locking of nondirectories for NFSv4
- ext4: split cross-rename and plain rename into separate functions
- introduce i_op->rename2 with flags, don't touch ->rename
- last (optional) patch to merge ->rename2 back into ->r
27 matches
Mail list logo
