Home
last modified time | relevance | path

Searched hist:"5 ac00add" (Results 1 – 3 of 3) sorted by relevance

/openbmc/linux/fs/btrfs/
H A Dioctl.c9b53157a Mon Mar 04 11:28:38 CST 2013 Stefan Behrens <sbehrens@giantdisaster.de> Btrfs: allow running defrag in parallel to administrative tasks

Commit 5ac00add added a testnset mutex and code that disallows
running administrative tasks in parallel. It is prevented that
the device add/delete/balance/replace/resize operations are
started in parallel. By mistake, the defragmentation operation
was included in the check for mutually exclusiveness as well.
This is fixed with this commit.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2c0c9da0 Sun Jan 20 07:57:57 CST 2013 Ilya Dryomov <idryomov@gmail.com> Btrfs: fix "mutually exclusive op is running" error code

The error code that is returned in response to starting a mutually
exclusive operation when there is one already running got silently
changed from EINVAL to EINPROGRESS by 5ac00add. Returning EINPROGRESS
to, say, add_dev, when rm_dev is running is misleading. Furthermore,
the operation itself may want to use EINPROGRESS for other purposes.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
ed0fb78f Sun Jan 20 07:57:57 CST 2013 Ilya Dryomov <idryomov@gmail.com> Btrfs: bring back balance pause/resume logic

Balance pause/resume logic got broken by 5ac00add (went in into 3.8-rc1
as part of dev-replace merge). Offending commit took a stab at making
mutually exclusive volume operations (add_dev, rm_dev, resize, balance,
replace_dev) not block behind volume_mutex if another such operation is
in progress and instead return an error right away. Balancing front-end
relied on the blocking behaviour, so the fix is ugly, but short of a
complete rework, it's the best we can do.

Reported-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
5ac00add Mon Nov 05 10:54:08 CST 2012 Stefan Behrens <sbehrens@giantdisaster.de> Btrfs: disallow mutually exclusive admin operations from user mode

Btrfs admin operations that are manually started from user mode
and that cannot be executed at the same time return -EINPROGRESS.
A common way to enter and leave this locked section is introduced
since it used to be specific to the balance operation.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
9b53157a Mon Mar 04 11:28:38 CST 2013 Stefan Behrens <sbehrens@giantdisaster.de> Btrfs: allow running defrag in parallel to administrative tasks

Commit 5ac00add added a testnset mutex and code that disallows
running administrative tasks in parallel. It is prevented that
the device add/delete/balance/replace/resize operations are
started in parallel. By mistake, the defragmentation operation
was included in the check for mutually exclusiveness as well.
This is fixed with this commit.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
2c0c9da0 Sun Jan 20 07:57:57 CST 2013 Ilya Dryomov <idryomov@gmail.com> Btrfs: fix "mutually exclusive op is running" error code

The error code that is returned in response to starting a mutually
exclusive operation when there is one already running got silently
changed from EINVAL to EINPROGRESS by 5ac00add. Returning EINPROGRESS
to, say, add_dev, when rm_dev is running is misleading. Furthermore,
the operation itself may want to use EINPROGRESS for other purposes.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
ed0fb78f Sun Jan 20 07:57:57 CST 2013 Ilya Dryomov <idryomov@gmail.com> Btrfs: bring back balance pause/resume logic

Balance pause/resume logic got broken by 5ac00add (went in into 3.8-rc1
as part of dev-replace merge). Offending commit took a stab at making
mutually exclusive volume operations (add_dev, rm_dev, resize, balance,
replace_dev) not block behind volume_mutex if another such operation is
in progress and instead return an error right away. Balancing front-end
relied on the blocking behaviour, so the fix is ugly, but short of a
complete rework, it's the best we can do.

Reported-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
5ac00add Mon Nov 05 10:54:08 CST 2012 Stefan Behrens <sbehrens@giantdisaster.de> Btrfs: disallow mutually exclusive admin operations from user mode

Btrfs admin operations that are manually started from user mode
and that cannot be executed at the same time return -EINPROGRESS.
A common way to enter and leave this locked section is introduced
since it used to be specific to the balance operation.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
H A Dvolumes.ced0fb78f Sun Jan 20 07:57:57 CST 2013 Ilya Dryomov <idryomov@gmail.com> Btrfs: bring back balance pause/resume logic

Balance pause/resume logic got broken by 5ac00add (went in into 3.8-rc1
as part of dev-replace merge). Offending commit took a stab at making
mutually exclusive volume operations (add_dev, rm_dev, resize, balance,
replace_dev) not block behind volume_mutex if another such operation is
in progress and instead return an error right away. Balancing front-end
relied on the blocking behaviour, so the fix is ugly, but short of a
complete rework, it's the best we can do.

Reported-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
5ac00add Mon Nov 05 10:54:08 CST 2012 Stefan Behrens <sbehrens@giantdisaster.de> Btrfs: disallow mutually exclusive admin operations from user mode

Btrfs admin operations that are manually started from user mode
and that cannot be executed at the same time return -EINPROGRESS.
A common way to enter and leave this locked section is introduced
since it used to be specific to the balance operation.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
ed0fb78f Sun Jan 20 07:57:57 CST 2013 Ilya Dryomov <idryomov@gmail.com> Btrfs: bring back balance pause/resume logic

Balance pause/resume logic got broken by 5ac00add (went in into 3.8-rc1
as part of dev-replace merge). Offending commit took a stab at making
mutually exclusive volume operations (add_dev, rm_dev, resize, balance,
replace_dev) not block behind volume_mutex if another such operation is
in progress and instead return an error right away. Balancing front-end
relied on the blocking behaviour, so the fix is ugly, but short of a
complete rework, it's the best we can do.

Reported-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
5ac00add Mon Nov 05 10:54:08 CST 2012 Stefan Behrens <sbehrens@giantdisaster.de> Btrfs: disallow mutually exclusive admin operations from user mode

Btrfs admin operations that are manually started from user mode
and that cannot be executed at the same time return -EINPROGRESS.
A common way to enter and leave this locked section is introduced
since it used to be specific to the balance operation.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
H A Dctree.h5ac00add Mon Nov 05 10:54:08 CST 2012 Stefan Behrens <sbehrens@giantdisaster.de> Btrfs: disallow mutually exclusive admin operations from user mode

Btrfs admin operations that are manually started from user mode
and that cannot be executed at the same time return -EINPROGRESS.
A common way to enter and leave this locked section is introduced
since it used to be specific to the balance operation.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
5ac00add Mon Nov 05 10:54:08 CST 2012 Stefan Behrens <sbehrens@giantdisaster.de> Btrfs: disallow mutually exclusive admin operations from user mode

Btrfs admin operations that are manually started from user mode
and that cannot be executed at the same time return -EINPROGRESS.
A common way to enter and leave this locked section is introduced
since it used to be specific to the balance operation.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>