Re: BTRFS file clone support for cp
Jim Meyering j...@meyering.net 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 the new behavior on a new option avoids the current semantic change we would otherwise induce in cp. I don't see how semantics change in a user visible way. -Andi -- a...@linux.intel.com -- Speaking for myself only. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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-place, and that knows it doesn't need to check for ENOSPC. Sure, they should always check for write failure, but still. It is a change. Fair point, although I suspect there are cases where ENOSPC on non extending write can already happen on specific file systems. e.g. on btrfs it might happen when the tree gets rebalanced? Or perhaps on nilfs2 when the garbage collector doesn't run in time. Wouldn't surprise me if there weren't more cases already. -Andi -- a...@linux.intel.com -- Speaking for myself only. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: functions statically linked on x86_64 while i386 uses glibc functions
[*] Can you even get a 2GB-long string into expr? At least on Linux you can't, the kernel limits arguments and environments to 128K or so. There are some patches floating around to enlarge that limit, but I don't think it will be ever 2GB because it would be too risky to pin that much memory unswappable. I think the others can only get regexprs from command line options too. It would only make sense if you have a option to input the regexpr from a file, which neither expr nor nl nor tac have. So I guess at least on Linux this doesn't make sense. -Andi ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
functions statically linked on x86_64 while i386 uses glibc functions
Hello, I was doing some binary size comparisons between -m32 and -m64 builds on x86_64 Linux (SUSE 10.2 with gcc 4.1.2). This is the same build environment, same glibc, etc. just one configured for i386-linux and built with -m32 and the other for x86_64-linux One thing I noticed is that a few executable sizes differ widely: (.text sizes) 64bit 32bit ./src/csplit95481 27704 ./src/nl87879 19551 ./src/ptx 98316 28623 ./src/expr 88373 20731 ./src/tac 83726 15935 The other differences are in the expected range of a few percent. On some investigation it looks like 64bit contains the regexpr functions and some other library functions, while the 32bit versions use the one from glibc. I assume that must be a (harmless) bug since the glibc version (2.5) is identical between 32bit and 64bit. A diff of the two config.logs is available at http://one.firstfloor.org/~andi/coreutils-conf-diff -Andi ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
