Re: BTRFS file clone support for cp

Joel Becker wrote: > On Wed, Jul 29, 2009 at 07:14:37PM +0100, Pádraig Brady wrote: >> Chris Mason wrote: >> > On Wed, Jul 29, 2009 at 03:14:49PM +0100, Pádraig Brady wrote: >> >> >> >> We may need to play around with fallocate() >> >> if we want to get back to the original >> >> cp semantics of a

Re: BTRFS file clone support for cp

On Thu, Jul 30, 2009 at 09:39:17AM +0200, Jim Meyering wrote: > Joel Becker wrote: > > I've cooked up 'ln -r' for reflinks, which works for ln(1) but > > not for cp(1). > > Thanks. I haven't looked, but after reading about the reflink syscall > [http://lwn.net/Articles/332802/] had come to th

Re: BTRFS file clone support for cp

Giuseppe Scrivano wrote: > Hi, > > I cleaned a bit the Pádraig's example in a new test case. > > The second patch fixes a problem that I introduced with the commit > e81c4d88c2fce526c02693d539e22c7468dc452b. Thanks for the test. We should be able to use it regardless of whether the feature is add

Re: BTRFS file clone support for cp

Jim Meyering wrote: > Joel Becker wrote: > >> On Wed, Jul 29, 2009 at 07:14:37PM +0100, Pádraig Brady wrote: >>> >>> At the moment we have these linking options: >>> >>> cp -l, --link #for hardlinks >>> cp -s, --symbolic-link #for symlinks >>> >>> So perhaps we should support: >>> >>> cp --link={s

Re: BTRFS file clone support for cp

Andi Kleen wrote: > Jim Meyering writes: >> Thanks. I haven't looked, but after reading about the reflink syscall >> [http://lwn.net/Articles/332802/] had come to the same conclusion: >> this feature belongs with ln rather than with cp. > > cp already has -l so it would make sense to extend that

Re: BTRFS file clone support for cp

Andi Kleen wrote: > Jim Meyering writes: >> >> Thanks. I haven't looked, but after reading about the reflink syscall >> [http://lwn.net/Articles/332802/] had come to the same conclusion: >> this feature belongs with ln rather than with cp. > > cp already has -l so it would make sense to extend t

Re: new module: update-copyright [Re: copyright years: mass-update every January 1

Joel E. Denny wrote: > On Wed, 29 Jul 2009, Jim Meyering wrote: > >> Joel E. Denny wrote: >> >> > On Wed, 29 Jul 2009, Jim Meyering wrote: >> > >> >> Joel E. Denny wrote: >> > >> >> > I'd like to use this in Bison. Would you consider contributing >> >> > build-aux/update-copyright to gnulib so we

Re: new module: update-copyright [Re: copyright years: mass-update every January 1

On Thu, 30 Jul 2009, Jim Meyering wrote: > Thank you! Thank you. :) > Here's an incremental change I'm about to fold into yours. > It changes "comment" to "prefix" and adjusts syntax. Makes sense. > There remains at least one infelicity: if someone discusses > the Copyright (C) notation (e.g.

Re: tail -f: --pid *and* inotify

I found another bug I think. Hopefully the attached is OK, but I'm not able to compile/test/push at the moment due to gnulib submodule weirdness. cheers, Pádraig. >From 45e2e5f26d4d7641c3ef2bfc3e47aab5bc93b8fe Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= Date: Thu, 30 Jul 2009

Re: BTRFS file clone support for cp

Jim Meyering wrote: > diff --git a/tests/tail-2/pid b/tests/tail-2/pid > > +# Ensure that tail --pid=PID exits successfully when PID is dead. > +# Use an unlikely-to-be-live PID: 2^31-1 > +getlimits_ > +tail --pid=$INT_MAX -f /dev/null || fail=1 Probably should use $PID_T_MAX You could speed up t

Re: BTRFS file clone support for cp

Pádraig Brady wrote: > Jim Meyering wrote: >> diff --git a/tests/tail-2/pid b/tests/tail-2/pid >> >> +# Ensure that tail --pid=PID exits successfully when PID is dead. >> +# Use an unlikely-to-be-live PID: 2^31-1 >> +getlimits_ >> +tail --pid=$INT_MAX -f /dev/null || fail=1 > > Probably should use

Re: tail -f: --pid *and* inotify

Pádraig Brady wrote: > I found another bug I think. > > Hopefully the attached is OK, but > I'm not able to compile/test/push at the moment > due to gnulib submodule weirdness. Thanks! Pushed. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http:/

[PATCH] tests: new function: require_openat_support_

I'm about to use this function in a new test, so... >From c06547cadeed50e85b1de661634a39f7321e562c Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 29 Jul 2009 14:59:27 +0200 Subject: [PATCH] tests: new function: require_openat_support_ * tests/rm/inaccessible: Factor out openat-support-de

[PATCH] cp: preserve time stamps on symlinks, too

This patch may not be ready for prime time. I wrote it and the test a few days ago, but haven't gone back and looked closely. There are just too many branches and use cases, and I'm sure I haven't considered all of them. However, all tests do pass, at least on recent gnu/linux systems. If anyone

Re: BTRFS file clone support for cp

Jim Meyering writes: > > Thanks. I haven't looked, but after reading about the reflink syscall > [http://lwn.net/Articles/332802/] had come to the same conclusion: > this feature belongs with ln rather than with cp. cp already has -l so it would make sense to extend that too. > Besides, putting

Re: BTRFS file clone support for cp

Jim Meyering wrote: With classic cp, if I copy a 1GB non-sparse file and there's less space than that available, cp fails with ENOSPC. With this new feature, it succeeds even if there are just a few blocks available. Is it good or bad? Also, consider (buggy!) code that then depends on being

Re: BTRFS file clone support for cp

> > With classic cp, if I copy a 1GB non-sparse file and there's less > space than that available, cp fails with ENOSPC. > With this new feature, it succeeds even if there are > just a few blocks available. > > Also, consider (buggy!) code that then depends on being able to modify > that file in-

Re: BTRFS file clone support for cp

On 07/30/2009 04:40 AM, Pádraig Brady wrote: Jim Meyering wrote: Joel Becker wrote: On Wed, Jul 29, 2009 at 07:14:37PM +0100, Pádraig Brady wrote: At the moment we have these linking options: cp -l, --link #for hardlinks cp -s, --symbolic-link #for symlinks So perhaps we s

Re: BTRFS file clone support for cp

Ric Wheeler wrote: > I think that doing reflink by default would be a horrible idea - one > good reason to copy a file is to increase your level of fault > tolerance and reflink magically avoids that :-) Good point. This would constitute another user-visible semantic change in cp: a disk fault tha

Re: BTRFS file clone support for cp

Hi Pádraig, thanks for the comments. Pádraig Brady writes: > # 300MB seems to be the minimum size for a btrfs with default > parameters. Actually, it seems the minimum space required is 256MB. Using a 255MB image I get: "device btrfs.img is too small (must be at least 256 MB)" > # FIXME: us

Re: BTRFS file clone support for cp

On Thu, Jul 30, 2009 at 12:54:16PM +0200, Andi Kleen wrote: > > With classic cp, if I copy a 1GB non-sparse file and there's less > > space than that available, cp fails with ENOSPC. > > With this new feature, it succeeds even if there are > > just a few blocks available. > > > > Also, consider (b

Re: BTRFS file clone support for cp

Joel Becker wrote: > In some sense, using btrfs, nilfs2i, ocfs2 with refcount trees > enabled, or any other CoW-ish filesystem is a tacit approval of the > delayed ENOSPC. The same can be said of "thin provisioning" LUNs. > However, the other concerns are still valid. A user invoking vanill

Re: BTRFS file clone support for cp

Giuseppe Scrivano wrote: > Hi Pádraig, > > thanks for the comments. > > Pádraig Brady writes: > >> # 300MB seems to be the minimum size for a btrfs with default >> parameters. > > Actually, it seems the minimum space required is 256MB. Using a 255MB > image I get: "device btrfs.img is too sma

[bug #27146] cp --no-preserve=mode is counter-intuitive

URL: Summary: cp --no-preserve=mode is counter-intuitive Project: GNU Core Utilities Submitted by: None Submitted on: Чтв 30 Июл 2009 23:57:13 Category: None Severity: