On Mon, Jan 28, 2013 at 01:22:30PM +0800, Anand Jain wrote:
The definition of the function open_file_or_dir() is moved from common.c
to utils.c in order to be able to share some common code between scrub
and the device stats in the following step. That common code uses
open_file_or_dir().
Good to have the old src-code removed as well.
yum snapshot plugin is out of btrfsctl.
http://lists.baseurl.org/pipermail/yum-devel/2012-July/009396.html
Thanks, Anand
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to
The definition of the function open_file_or_dir() is moved from common.c
to utils.c in order to be able to share some common code between scrub
and the device stats in the following step. That common code uses
open_file_or_dir(). Since open_file_or_dir() makes use of the function
dirfd(3), the
The definition of the function open_file_or_dir() is moved from common.c
to utils.c in order to be able to share some common code between scrub
and the device stats in the following step. That common code uses
open_file_or_dir(). Since open_file_or_dir() makes use of the function
dirfd(3), the
The definition of the function open_file_or_dir() is moved from common.c
to utils.c in order to be able to share some common code between scrub
and the device stats in the following step. That common code uses
open_file_or_dir(). Since open_file_or_dir() makes use of the function
dirfd(3), the
Cool, I had this on my stack too. But can you maybe remove the
nonsensical return values, and instead of renaming keeping the btrfsctl.c
copy, why not just use a common copy in utils.c? It'd just be 2 checks
for fd 0 in the btrfsctl callers.
Thanks for the comments Eric. Though I agree,
The definition of the function open_file_or_dir() is moved from common.c
to utils.c in order to be able to share some common code between scrub
and the device stats in the following step. That common code uses
open_file_or_dir(). Since open_file_or_dir() makes use of the function
dirfd(3), the
On 1/24/13 1:42 PM, Eric Sandeen wrote:
On 1/24/13 11:57 AM, Goffredo Baroncelli wrote:
On 01/24/2013 10:23 AM, Stefan Behrens wrote:
On Wed, 23 Jan 2013 22:39:29 -0600, Eric Sandeen wrote:
instead of renaming keeping the btrfsctl.c copy
There is a new momentum to improve the Btrfs-progs
On 1/24/13 4:09 PM, Goffredo Baroncelli wrote:
On 01/24/2013 08:42 PM, Eric Sandeen wrote:
On 1/24/13 11:57 AM, Goffredo Baroncelli wrote:
On 01/24/2013 10:23 AM, Stefan Behrens wrote:
On Wed, 23 Jan 2013 22:39:29 -0600, Eric Sandeen wrote:
instead of renaming keeping the btrfsctl.c copy
On Fri, Jan 25, 2013 at 10:14:06AM -0600, Eric Sandeen wrote:
On 1/24/13 4:09 PM, Goffredo Baroncelli wrote:
On 01/24/2013 08:42 PM, Eric Sandeen wrote:
On 1/24/13 11:57 AM, Goffredo Baroncelli wrote:
On 01/24/2013 10:23 AM, Stefan Behrens wrote:
On Wed, 23 Jan 2013 22:39:29 -0600, Eric
On 01/25/2013 11:48 AM, Hugo Mills wrote:
On Fri, Jan 25, 2013 at 10:14:06AM -0600, Eric Sandeen wrote:
On 1/24/13 4:09 PM, Goffredo Baroncelli wrote:
On 01/24/2013 08:42 PM, Eric Sandeen wrote:
On 1/24/13 11:57 AM, Goffredo Baroncelli wrote:
On 01/24/2013 10:23 AM, Stefan Behrens wrote:
On
On 01/24/2013 10:23 AM, Stefan Behrens wrote:
On Wed, 23 Jan 2013 22:39:29 -0600, Eric Sandeen wrote:
instead of renaming keeping the btrfsctl.c copy
There is a new momentum to improve the Btrfs-progs quality :)
IMO, one step is to get rid of the legacy tools and sources. It wastes
time to
On 1/24/13 11:57 AM, Goffredo Baroncelli wrote:
On 01/24/2013 10:23 AM, Stefan Behrens wrote:
On Wed, 23 Jan 2013 22:39:29 -0600, Eric Sandeen wrote:
instead of renaming keeping the btrfsctl.c copy
There is a new momentum to improve the Btrfs-progs quality :)
IMO, one step is to get rid of
On 01/24/2013 08:42 PM, Eric Sandeen wrote:
On 1/24/13 11:57 AM, Goffredo Baroncelli wrote:
On 01/24/2013 10:23 AM, Stefan Behrens wrote:
On Wed, 23 Jan 2013 22:39:29 -0600, Eric Sandeen wrote:
instead of renaming keeping the btrfsctl.c copy
There is a new momentum to improve the
On Thu, Jan 24, 2013 at 03:09:53PM -0700, Goffredo Baroncelli wrote:
On 01/24/2013 08:42 PM, Eric Sandeen wrote:
On 1/24/13 11:57 AM, Goffredo Baroncelli wrote:
On 01/24/2013 10:23 AM, Stefan Behrens wrote:
On Wed, 23 Jan 2013 22:39:29 -0600, Eric Sandeen wrote:
instead of renaming
On Thu, Jan 24, 2013 at 05:36:52PM -0500, Chris Mason wrote:
On Thu, Jan 24, 2013 at 03:09:53PM -0700, Goffredo Baroncelli wrote:
The same is true for the debian package, but are these used in Fedora ?
For backwards compat, could those be turned into shell scripts which
invoke the btrfs
Hey Chris,
On 25/01/2013, at 9:36 AM, Chris Mason chris.ma...@fusionio.com wrote:
I'd say that if SuSE or oracle depend on them we keep them. Otherwise,
I'm fine with removing them or just making the 3 line bash script.
You can take this as an official response from Oracle: we don't
The definition of the function open_file_or_dir() is moved from common.c
to utils.c in order to be able to share some common code between scrub
and the device stats in the following step. That common code uses
open_file_or_dir(). Since open_file_or_dir() makes use of the function
dirfd(3), the
On 1/23/13 2:12 AM, Anand Jain wrote:
The definition of the function open_file_or_dir() is moved from common.c
to utils.c in order to be able to share some common code between scrub
and the device stats in the following step. That common code uses
open_file_or_dir(). Since open_file_or_dir()
19 matches
Mail list logo