quotas: failure on removing a file via SFTP/SSH

quotas: failure on removing a file via SFTP/SSH

[ST]

Hello,

I'm trying to use quotas for a simple chrooted sftp setup, limiting
space for each user's subvolume (now for testing to 1M).

I tried to hit the limit by uploading files and once it comes to the
limit I face following problem: if I try to free space by removing a
file via Linux sftp client (or Filezilla) - I get error:
"Couldn't delete file: Failure"

Sometimes, but not always, if I repeat it for 3-5 times it does removes
the file at the end.
If I login as root and try to remove the file via SSH I get the error:
"rm: cannot remove 'example.txt': Disk quota exceeded"

What is the problem? And how can I solve it?

Thank you in advance!

Re: quotas: failure on removing a file via SFTP/SSH

[Lakshmipathi.G]

Seems like issue is similar to this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=197681
Whats your kernel/brtfs-prog version? Can you upgrade them to latest
if they are quite old?
----
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org


On Tue, Nov 21, 2017 at 5:38 PM, ST <smntov@gmail.com> wrote:
> Hello,
>
> I'm trying to use quotas for a simple chrooted sftp setup, limiting
> space for each user's subvolume (now for testing to 1M).
>
> I tried to hit the limit by uploading files and once it comes to the
> limit I face following problem: if I try to free space by removing a
> file via Linux sftp client (or Filezilla) - I get error:
> "Couldn't delete file: Failure"
>
> Sometimes, but not always, if I repeat it for 3-5 times it does removes
> the file at the end.
> If I login as root and try to remove the file via SSH I get the error:
> "rm: cannot remove 'example.txt': Disk quota exceeded"
>
> What is the problem? And how can I solve it?
>
> Thank you in advance!
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: quotas: failure on removing a file via SFTP/SSH

[ST]

I am on Debian 9 (stable), so kernel version is:
uname -r
4.9.0-4-amd64

btrfs-tools (4.7.3-1)

It might be related to the bug you have referred to (since once I hit
the quota limit I tried then to add some small files to check whether
quota works). However my main problem is - why I can't REMOVE files?! I
get error while I try to free space!

In my real use case I'll have quota limit of minimum 100G, is it
possible that the issue is caused by the small 1M (test) limit and will
not appear in real use case?

Thank you!


On Tue, 2017-11-21 at 17:55 +0530, Lakshmipathi.G wrote:
> Seems like issue is similar to this bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=197681
> Whats your kernel/brtfs-prog version? Can you upgrade them to latest
> if they are quite old?
> ----
> Cheers,
> Lakshmipathi.G
> http://www.giis.co.in http://www.webminal.org
> 
> 
> On Tue, Nov 21, 2017 at 5:38 PM, ST <smntov@gmail.com> wrote:
> > Hello,
> >
> > I'm trying to use quotas for a simple chrooted sftp setup, limiting
> > space for each user's subvolume (now for testing to 1M).
> >
> > I tried to hit the limit by uploading files and once it comes to the
> > limit I face following problem: if I try to free space by removing a
> > file via Linux sftp client (or Filezilla) - I get error:
> > "Couldn't delete file: Failure"
> >
> > Sometimes, but not always, if I repeat it for 3-5 times it does removes
> > the file at the end.
> > If I login as root and try to remove the file via SSH I get the error:
> > "rm: cannot remove 'example.txt': Disk quota exceeded"
> >
> > What is the problem? And how can I solve it?
> >
> > Thank you in advance!
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: quotas: failure on removing a file via SFTP/SSH

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 1565 bytes --]



On 2017年11月21日 20:08, ST wrote:
> Hello,
> 
> I'm trying to use quotas for a simple chrooted sftp setup, limiting
> space for each user's subvolume (now for testing to 1M).
> 
> I tried to hit the limit by uploading files and once it comes to the
> limit I face following problem: if I try to free space by removing a
> file via Linux sftp client (or Filezilla) - I get error:
> "Couldn't delete file: Failure"
> 
> Sometimes, but not always, if I repeat it for 3-5 times it does removes
> the file at the end.
> If I login as root and try to remove the file via SSH I get the error:
> "rm: cannot remove 'example.txt': Disk quota exceeded"
> 
> What is the problem? And how can I solve it?

Kernel version first.

If it's possible, please use latest kernel, at least newer than v4.10,
since we have a lot of qgroup reservation related fixes in newer kernel.

Then, for small quota, due to the nature of btrfs metadata CoW and
relative large default node size (16K), it's quite easy to hit disk
quota for metadata.

So it's not really useful for such small quota usage.
If you really want to use quota for small limit, at least use small
nodesize.

And if you hit -EDQUOTA, normally you could try to sync the fs to free
some reserved space, then try again.

Thanks,
Qu
> 
> Thank you in advance!
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: quotas: failure on removing a file via SFTP/SSH

[ST]

On Tue, 2017-11-21 at 20:28 +0800, Qu Wenruo wrote:
> 
> On 2017年11月21日 20:08, ST wrote:
> > Hello,
> > 
> > I'm trying to use quotas for a simple chrooted sftp setup, limiting
> > space for each user's subvolume (now for testing to 1M).
> > 
> > I tried to hit the limit by uploading files and once it comes to the
> > limit I face following problem: if I try to free space by removing a
> > file via Linux sftp client (or Filezilla) - I get error:
> > "Couldn't delete file: Failure"
> > 
> > Sometimes, but not always, if I repeat it for 3-5 times it does removes
> > the file at the end.
> > If I login as root and try to remove the file via SSH I get the error:
> > "rm: cannot remove 'example.txt': Disk quota exceeded"
> > 
> > What is the problem? And how can I solve it?
> 
> Kernel version first.
> 
> If it's possible, please use latest kernel, at least newer than v4.10,
> since we have a lot of qgroup reservation related fixes in newer kernel.
> 
> Then, for small quota, due to the nature of btrfs metadata CoW and
> relative large default node size (16K), it's quite easy to hit disk
> quota for metadata.

Yes, but why I get the error specifically on REMOVING a file? Even if I
hit disk quota - if I free up space - it should be possible, isn't it?

> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 

Re: quotas: failure on removing a file via SFTP/SSH

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 1807 bytes --]



On 2017年11月21日 21:18, ST wrote:
> 
> 
> 
> On Tue, 2017-11-21 at 20:28 +0800, Qu Wenruo wrote:
>>
>> On 2017年11月21日 20:08, ST wrote:
>>> Hello,
>>>
>>> I'm trying to use quotas for a simple chrooted sftp setup, limiting
>>> space for each user's subvolume (now for testing to 1M).
>>>
>>> I tried to hit the limit by uploading files and once it comes to the
>>> limit I face following problem: if I try to free space by removing a
>>> file via Linux sftp client (or Filezilla) - I get error:
>>> "Couldn't delete file: Failure"
>>>
>>> Sometimes, but not always, if I repeat it for 3-5 times it does removes
>>> the file at the end.
>>> If I login as root and try to remove the file via SSH I get the error:
>>> "rm: cannot remove 'example.txt': Disk quota exceeded"
>>>
>>> What is the problem? And how can I solve it?
>>
>> Kernel version first.
>>
>> If it's possible, please use latest kernel, at least newer than v4.10,
>> since we have a lot of qgroup reservation related fixes in newer kernel.
>>
>> Then, for small quota, due to the nature of btrfs metadata CoW and
>> relative large default node size (16K), it's quite easy to hit disk
>> quota for metadata.
> 
> Yes, but why I get the error specifically on REMOVING a file? Even if I
> hit disk quota - if I free up space - it should be possible, isn't it?

It's only true for fs modifying its metadata in-place (and use journal
to protect it).

For fs using metadata CoW, even freeing space needs extra space for new
metadata.

Thanks,
Qu

> 
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: quotas: failure on removing a file via SFTP/SSH

[ST]

> >>> I'm trying to use quotas for a simple chrooted sftp setup, limiting
> >>> space for each user's subvolume (now for testing to 1M).
> >>>
> >>> I tried to hit the limit by uploading files and once it comes to the
> >>> limit I face following problem: if I try to free space by removing a
> >>> file via Linux sftp client (or Filezilla) - I get error:
> >>> "Couldn't delete file: Failure"
> >>>
> >>> Sometimes, but not always, if I repeat it for 3-5 times it does removes
> >>> the file at the end.
> >>> If I login as root and try to remove the file via SSH I get the error:
> >>> "rm: cannot remove 'example.txt': Disk quota exceeded"
> >>>
> >>> What is the problem? And how can I solve it?
> >>
> >> Kernel version first.
> >>
> >> If it's possible, please use latest kernel, at least newer than v4.10,
> >> since we have a lot of qgroup reservation related fixes in newer kernel.
> >>
> >> Then, for small quota, due to the nature of btrfs metadata CoW and
> >> relative large default node size (16K), it's quite easy to hit disk
> >> quota for metadata.
> > 
> > Yes, but why I get the error specifically on REMOVING a file? Even if I
> > hit disk quota - if I free up space - it should be possible, isn't it?
> 
> It's only true for fs modifying its metadata in-place (and use journal
> to protect it).
> 
> For fs using metadata CoW, even freeing space needs extra space for new
> metadata.
> 

Wait, it doesn't sound like a bug, but rather like a flaw in design.
This means - each time a user hits his quota limit he will get stuck
without being able to free space?!!

Thank you.

Re: quotas: failure on removing a file via SFTP/SSH

[Chris Murphy]

On Tue, Nov 21, 2017 at 8:29 AM, ST <smntov@gmail.com> wrote:
>> >>> I'm trying to use quotas for a simple chrooted sftp setup, limiting
>> >>> space for each user's subvolume (now for testing to 1M).
>> >>>
>> >>> I tried to hit the limit by uploading files and once it comes to the
>> >>> limit I face following problem: if I try to free space by removing a
>> >>> file via Linux sftp client (or Filezilla) - I get error:
>> >>> "Couldn't delete file: Failure"
>> >>>
>> >>> Sometimes, but not always, if I repeat it for 3-5 times it does removes
>> >>> the file at the end.
>> >>> If I login as root and try to remove the file via SSH I get the error:
>> >>> "rm: cannot remove 'example.txt': Disk quota exceeded"
>> >>>
>> >>> What is the problem? And how can I solve it?
>> >>
>> >> Kernel version first.
>> >>
>> >> If it's possible, please use latest kernel, at least newer than v4.10,
>> >> since we have a lot of qgroup reservation related fixes in newer kernel.
>> >>
>> >> Then, for small quota, due to the nature of btrfs metadata CoW and
>> >> relative large default node size (16K), it's quite easy to hit disk
>> >> quota for metadata.
>> >
>> > Yes, but why I get the error specifically on REMOVING a file? Even if I
>> > hit disk quota - if I free up space - it should be possible, isn't it?
>>
>> It's only true for fs modifying its metadata in-place (and use journal
>> to protect it).
>>
>> For fs using metadata CoW, even freeing space needs extra space for new
>> metadata.
>>
>
> Wait, it doesn't sound like a bug, but rather like a flaw in design.
> This means - each time a user hits his quota limit he will get stuck
> without being able to free space?!!

It's a good question if quotas can make it possible for a user to get
wedged into a situation that will require an admin to temporarily
raise the quota in order to make file deletion possible. This is not a
design flaw, all COW file systems *add* data when deleting. The
challenge is how to teach the quota system to act like a hard limit
for data writes that clearly bust the quota, versus a soft limit that
tolerates some extra amount above the quota for the purpose of
eventually deleting data. That's maybe non-trivial. It's not that it's
a design flaw. Metadata can contain inline data, so how exactly to you
tell what kinds of writes are permitted (deleting a file) and what
kind of writes are not (append data to a file, or create new file)?

But for sure the user space tools should prevent setting too low a
quota limit. If the limit cannot be reasonably expected to work, it
should be disallowed. So maybe the user space tools need to enforce a
minimum quota, something like 100MiB, or whatever.



-- 
Chris Murphy

Re: quotas: failure on removing a file via SFTP/SSH

[ST]

On Tue, 2017-11-21 at 11:33 -0700, Chris Murphy wrote:
> On Tue, Nov 21, 2017 at 8:29 AM, ST <smntov@gmail.com> wrote:
> >> >>> I'm trying to use quotas for a simple chrooted sftp setup, limiting
> >> >>> space for each user's subvolume (now for testing to 1M).
> >> >>>
> >> >>> I tried to hit the limit by uploading files and once it comes to the
> >> >>> limit I face following problem: if I try to free space by removing a
> >> >>> file via Linux sftp client (or Filezilla) - I get error:
> >> >>> "Couldn't delete file: Failure"
> >> >>>
> >> >>> Sometimes, but not always, if I repeat it for 3-5 times it does removes
> >> >>> the file at the end.
> >> >>> If I login as root and try to remove the file via SSH I get the error:
> >> >>> "rm: cannot remove 'example.txt': Disk quota exceeded"
> >> >>>
> >> >>> What is the problem? And how can I solve it?
> >> >>
> >> >> Kernel version first.
> >> >>
> >> >> If it's possible, please use latest kernel, at least newer than v4.10,
> >> >> since we have a lot of qgroup reservation related fixes in newer kernel.
> >> >>
> >> >> Then, for small quota, due to the nature of btrfs metadata CoW and
> >> >> relative large default node size (16K), it's quite easy to hit disk
> >> >> quota for metadata.
> >> >
> >> > Yes, but why I get the error specifically on REMOVING a file? Even if I
> >> > hit disk quota - if I free up space - it should be possible, isn't it?
> >>
> >> It's only true for fs modifying its metadata in-place (and use journal
> >> to protect it).
> >>
> >> For fs using metadata CoW, even freeing space needs extra space for new
> >> metadata.
> >>
> >
> > Wait, it doesn't sound like a bug, but rather like a flaw in design.
> > This means - each time a user hits his quota limit he will get stuck
> > without being able to free space?!!
> 
> It's a good question if quotas can make it possible for a user to get
> wedged into a situation that will require an admin to temporarily
> raise the quota in order to make file deletion possible.

Why question? It's a fact. That's what I face right now.

>  This is not a
> design flaw, all COW file systems *add* data when deleting. The
> challenge is how to teach the quota system to act like a hard limit
> for data writes that clearly bust the quota, versus a soft limit that
> tolerates some extra amount above the quota for the purpose of
> eventually deleting data. That's maybe non-trivial. It's not that it's
> a design flaw. Metadata can contain inline data, so how exactly to you
> tell what kinds of writes are permitted (deleting a file) and what
> kind of writes are not (append data to a file, or create new file)?
> 
> But for sure the user space tools should prevent setting too low a
> quota limit. If the limit cannot be reasonably expected to work, it
> should be disallowed. So maybe the user space tools need to enforce a
> minimum quota, something like 100MiB, or whatever.
> 

Would you like to open an issue with your enhancement suggestions on the
bug tracker so this case doesn't get forgotten?

Thank you!

Re: quotas: failure on removing a file via SFTP/SSH

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 3556 bytes --]



On 2017年11月22日 05:00, ST wrote:
> On Tue, 2017-11-21 at 11:33 -0700, Chris Murphy wrote:
>> On Tue, Nov 21, 2017 at 8:29 AM, ST <smntov@gmail.com> wrote:
>>>>>>> I'm trying to use quotas for a simple chrooted sftp setup, limiting
>>>>>>> space for each user's subvolume (now for testing to 1M).
>>>>>>>
>>>>>>> I tried to hit the limit by uploading files and once it comes to the
>>>>>>> limit I face following problem: if I try to free space by removing a
>>>>>>> file via Linux sftp client (or Filezilla) - I get error:
>>>>>>> "Couldn't delete file: Failure"
>>>>>>>
>>>>>>> Sometimes, but not always, if I repeat it for 3-5 times it does removes
>>>>>>> the file at the end.
>>>>>>> If I login as root and try to remove the file via SSH I get the error:
>>>>>>> "rm: cannot remove 'example.txt': Disk quota exceeded"
>>>>>>>
>>>>>>> What is the problem? And how can I solve it?
>>>>>>
>>>>>> Kernel version first.
>>>>>>
>>>>>> If it's possible, please use latest kernel, at least newer than v4.10,
>>>>>> since we have a lot of qgroup reservation related fixes in newer kernel.
>>>>>>
>>>>>> Then, for small quota, due to the nature of btrfs metadata CoW and
>>>>>> relative large default node size (16K), it's quite easy to hit disk
>>>>>> quota for metadata.
>>>>>
>>>>> Yes, but why I get the error specifically on REMOVING a file? Even if I
>>>>> hit disk quota - if I free up space - it should be possible, isn't it?
>>>>
>>>> It's only true for fs modifying its metadata in-place (and use journal
>>>> to protect it).
>>>>
>>>> For fs using metadata CoW, even freeing space needs extra space for new
>>>> metadata.
>>>>
>>>
>>> Wait, it doesn't sound like a bug, but rather like a flaw in design.
>>> This means - each time a user hits his quota limit he will get stuck
>>> without being able to free space?!!
>>
>> It's a good question if quotas can make it possible for a user to get
>> wedged into a situation that will require an admin to temporarily
>> raise the quota in order to make file deletion possible.
> 
> Why question? It's a fact. That's what I face right now.
> 
>>  This is not a
>> design flaw, all COW file systems *add* data when deleting. The
>> challenge is how to teach the quota system to act like a hard limit
>> for data writes that clearly bust the quota, versus a soft limit that
>> tolerates some extra amount above the quota for the purpose of
>> eventually deleting data. That's maybe non-trivial. It's not that it's
>> a design flaw. Metadata can contain inline data, so how exactly to you
>> tell what kinds of writes are permitted (deleting a file) and what
>> kind of writes are not (append data to a file, or create new file)?
>>
>> But for sure the user space tools should prevent setting too low a
>> quota limit. If the limit cannot be reasonably expected to work, it
>> should be disallowed. So maybe the user space tools need to enforce a
>> minimum quota, something like 100MiB, or whatever.
>>
> 
> Would you like to open an issue with your enhancement suggestions on the
> bug tracker so this case doesn't get forgotten?

That's why I ask for the kernel version.

IIRC in newer kernel, quota doesn't limit deletion anymore, preventing
you from hitting such dilemma.

Thanks,
Qu
> 
> Thank you!
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: quotas: failure on removing a file via SFTP/SSH

[ST]

On Wed, 2017-11-22 at 08:39 +0800, Qu Wenruo wrote:
> 
> On 2017年11月22日 05:00, ST wrote:
> > On Tue, 2017-11-21 at 11:33 -0700, Chris Murphy wrote:
> >> On Tue, Nov 21, 2017 at 8:29 AM, ST <smntov@gmail.com> wrote:
> >>>>>>> I'm trying to use quotas for a simple chrooted sftp setup, limiting
> >>>>>>> space for each user's subvolume (now for testing to 1M).
> >>>>>>>
> >>>>>>> I tried to hit the limit by uploading files and once it comes to the
> >>>>>>> limit I face following problem: if I try to free space by removing a
> >>>>>>> file via Linux sftp client (or Filezilla) - I get error:
> >>>>>>> "Couldn't delete file: Failure"
> >>>>>>>
> >>>>>>> Sometimes, but not always, if I repeat it for 3-5 times it does removes
> >>>>>>> the file at the end.
> >>>>>>> If I login as root and try to remove the file via SSH I get the error:
> >>>>>>> "rm: cannot remove 'example.txt': Disk quota exceeded"
> >>>>>>>
> >>>>>>> What is the problem? And how can I solve it?
> >>>>>>
> >>>>>> Kernel version first.
> >>>>>>
> >>>>>> If it's possible, please use latest kernel, at least newer than v4.10,
> >>>>>> since we have a lot of qgroup reservation related fixes in newer kernel.
> >>>>>>
> >>>>>> Then, for small quota, due to the nature of btrfs metadata CoW and
> >>>>>> relative large default node size (16K), it's quite easy to hit disk
> >>>>>> quota for metadata.
> >>>>>
> >>>>> Yes, but why I get the error specifically on REMOVING a file? Even if I
> >>>>> hit disk quota - if I free up space - it should be possible, isn't it?
> >>>>
> >>>> It's only true for fs modifying its metadata in-place (and use journal
> >>>> to protect it).
> >>>>
> >>>> For fs using metadata CoW, even freeing space needs extra space for new
> >>>> metadata.
> >>>>
> >>>
> >>> Wait, it doesn't sound like a bug, but rather like a flaw in design.
> >>> This means - each time a user hits his quota limit he will get stuck
> >>> without being able to free space?!!
> >>
> >> It's a good question if quotas can make it possible for a user to get
> >> wedged into a situation that will require an admin to temporarily
> >> raise the quota in order to make file deletion possible.
> > 
> > Why question? It's a fact. That's what I face right now.
> > 
> >>  This is not a
> >> design flaw, all COW file systems *add* data when deleting. The
> >> challenge is how to teach the quota system to act like a hard limit
> >> for data writes that clearly bust the quota, versus a soft limit that
> >> tolerates some extra amount above the quota for the purpose of
> >> eventually deleting data. That's maybe non-trivial. It's not that it's
> >> a design flaw. Metadata can contain inline data, so how exactly to you
> >> tell what kinds of writes are permitted (deleting a file) and what
> >> kind of writes are not (append data to a file, or create new file)?
> >>
> >> But for sure the user space tools should prevent setting too low a
> >> quota limit. If the limit cannot be reasonably expected to work, it
> >> should be disallowed. So maybe the user space tools need to enforce a
> >> minimum quota, something like 100MiB, or whatever.
> >>
> > 
> > Would you like to open an issue with your enhancement suggestions on the
> > bug tracker so this case doesn't get forgotten?
> 
> That's why I ask for the kernel version.
> 
> IIRC in newer kernel, quota doesn't limit deletion anymore, preventing
> you from hitting such dilemma.

I'm sorry. I've mentioned it in another mail in this thread, here it is:

I am on Debian 9 (stable), so kernel version is:
uname -r
4.9.0-4-amd64
btrfs-tools (4.7.3-1)

I hope kernel 4.13 will move from Debian stable-backports to stable in
some not so distant future. Is this issue already resolved in 4.13?

Thank you!

Re: quotas: failure on removing a file via SFTP/SSH

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 4097 bytes --]



On 2017年11月22日 16:32, ST wrote:
> 
> 
> 
> On Wed, 2017-11-22 at 08:39 +0800, Qu Wenruo wrote:
>>
>> On 2017年11月22日 05:00, ST wrote:
>>> On Tue, 2017-11-21 at 11:33 -0700, Chris Murphy wrote:
>>>> On Tue, Nov 21, 2017 at 8:29 AM, ST <smntov@gmail.com> wrote:
>>>>>>>>> I'm trying to use quotas for a simple chrooted sftp setup, limiting
>>>>>>>>> space for each user's subvolume (now for testing to 1M).
>>>>>>>>>
>>>>>>>>> I tried to hit the limit by uploading files and once it comes to the
>>>>>>>>> limit I face following problem: if I try to free space by removing a
>>>>>>>>> file via Linux sftp client (or Filezilla) - I get error:
>>>>>>>>> "Couldn't delete file: Failure"
>>>>>>>>>
>>>>>>>>> Sometimes, but not always, if I repeat it for 3-5 times it does removes
>>>>>>>>> the file at the end.
>>>>>>>>> If I login as root and try to remove the file via SSH I get the error:
>>>>>>>>> "rm: cannot remove 'example.txt': Disk quota exceeded"
>>>>>>>>>
>>>>>>>>> What is the problem? And how can I solve it?
>>>>>>>>
>>>>>>>> Kernel version first.
>>>>>>>>
>>>>>>>> If it's possible, please use latest kernel, at least newer than v4.10,
>>>>>>>> since we have a lot of qgroup reservation related fixes in newer kernel.
>>>>>>>>
>>>>>>>> Then, for small quota, due to the nature of btrfs metadata CoW and
>>>>>>>> relative large default node size (16K), it's quite easy to hit disk
>>>>>>>> quota for metadata.
>>>>>>>
>>>>>>> Yes, but why I get the error specifically on REMOVING a file? Even if I
>>>>>>> hit disk quota - if I free up space - it should be possible, isn't it?
>>>>>>
>>>>>> It's only true for fs modifying its metadata in-place (and use journal
>>>>>> to protect it).
>>>>>>
>>>>>> For fs using metadata CoW, even freeing space needs extra space for new
>>>>>> metadata.
>>>>>>
>>>>>
>>>>> Wait, it doesn't sound like a bug, but rather like a flaw in design.
>>>>> This means - each time a user hits his quota limit he will get stuck
>>>>> without being able to free space?!!
>>>>
>>>> It's a good question if quotas can make it possible for a user to get
>>>> wedged into a situation that will require an admin to temporarily
>>>> raise the quota in order to make file deletion possible.
>>>
>>> Why question? It's a fact. That's what I face right now.
>>>
>>>>  This is not a
>>>> design flaw, all COW file systems *add* data when deleting. The
>>>> challenge is how to teach the quota system to act like a hard limit
>>>> for data writes that clearly bust the quota, versus a soft limit that
>>>> tolerates some extra amount above the quota for the purpose of
>>>> eventually deleting data. That's maybe non-trivial. It's not that it's
>>>> a design flaw. Metadata can contain inline data, so how exactly to you
>>>> tell what kinds of writes are permitted (deleting a file) and what
>>>> kind of writes are not (append data to a file, or create new file)?
>>>>
>>>> But for sure the user space tools should prevent setting too low a
>>>> quota limit. If the limit cannot be reasonably expected to work, it
>>>> should be disallowed. So maybe the user space tools need to enforce a
>>>> minimum quota, something like 100MiB, or whatever.
>>>>
>>>
>>> Would you like to open an issue with your enhancement suggestions on the
>>> bug tracker so this case doesn't get forgotten?
>>
>> That's why I ask for the kernel version.
>>
>> IIRC in newer kernel, quota doesn't limit deletion anymore, preventing
>> you from hitting such dilemma.
> 
> I'm sorry. I've mentioned it in another mail in this thread, here it is:
> 
> I am on Debian 9 (stable), so kernel version is:
> uname -r
> 4.9.0-4-amd64

This seems before the workaround for file deletion, but I can also be
wrong about it.

If you could try v4.13/14, it will be possible to verify the behavior.

Thanks,
Qu

> btrfs-tools (4.7.3-1)
> 
> I hope kernel 4.13 will move from Debian stable-backports to stable in
> some not so distant future. Is this issue already resolved in 4.13?
> 
> Thank you!
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]