On Mon, Feb 11, 2013 at 11:48:20AM -0600, Eric Sandeen wrote:
> On 2/11/13 11:45 AM, David Sterba wrote:
> > __btrfs_run_defrag_inode -> btrfs_defrag_file applies only in case of
> > autodefrag. The ioctl 'defrag' goes directly to btrfs_defrag_file and
> > what you describe does not happen here.
>
On 2/11/13 11:45 AM, David Sterba wrote:
> On Mon, Feb 11, 2013 at 10:59:54AM -0600, Eric Sandeen wrote:
>> On 2/9/13 5:38 PM, David Sterba wrote:
>>> The defrag operation can take very long, we want to have a way how to
>>> cancel it. The code checks for a pending signal at safe points in the
>>>
On Mon, Feb 11, 2013 at 10:59:54AM -0600, Eric Sandeen wrote:
> On 2/9/13 5:38 PM, David Sterba wrote:
> > The defrag operation can take very long, we want to have a way how to
> > cancel it. The code checks for a pending signal at safe points in the
> > defrag loops and returns EAGAIN. This means
On 2/9/13 5:38 PM, David Sterba wrote:
> The defrag operation can take very long, we want to have a way how to
> cancel it. The code checks for a pending signal at safe points in the
> defrag loops and returns EAGAIN. This means a user can press ^C after
> running 'btrfs fi defrag', woks for both d
The defrag operation can take very long, we want to have a way how to
cancel it. The code checks for a pending signal at safe points in the
defrag loops and returns EAGAIN. This means a user can press ^C after
running 'btrfs fi defrag', woks for both defrag modes, files and root.
Returning from th
