quotas: failure on removing a file via SFTP/SSH
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!
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
Quoted 24 lines · 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!
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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!
Quoted 35 lines · Lakshmipathi.G
Seems like issue is similar to this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=197681
Whats yourkernel/brtfs-progversion? Can you upgrade them to latest if they are quite old?
----
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.orgQuoted 24 lines · 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!
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · 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"
Quoted 6 lines
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
Quoted 9 lines
Thank you in advance!
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 19 lines · Qu Wenruo
Quoted 10 lines · 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"Quoted 6 lines
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?
Quoted 8 lines
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?
Quoted 8 lines
Quoted 7 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 28 lines · ST
Quoted 24 lines · Qu Wenruo
Quoted 10 lines · 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"Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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
Quoted 10 lines
Quoted 9 lines
Quoted 8 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 24 lines
Quoted 24 lines
Quoted 23 lines
Quoted 8 lines
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"Quoted 6 lines
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.
Quoted 9 lines
Quoted 2 lines
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.
Quoted 30 lines · ST
Quoted 30 lines
Quoted 20 lines
Quoted 20 lines
Quoted 8 lines
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"Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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).
Quoted 7 lines
Quoted 3 lines
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.
Signature · 1 line
Chris Murphy
Quoted 35 lines · Chris Murphy
Quoted 34 lines · ST
Quoted 33 lines
Quoted 20 lines
Quoted 20 lines
Quoted 8 lines
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"Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 10 lines
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)?
Quoted 5 lines
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!
Quoted 56 lines · ST
Quoted 35 lines · Chris Murphy
Quoted 34 lines · ST
Quoted 33 lines
Quoted 20 lines
Quoted 20 lines
Quoted 8 lines
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"Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 10 lines
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)?
Quoted 8 lines
Quoted 5 lines
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
Quoted 9 lines
Thank you!
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 64 lines · Qu Wenruo
Quoted 62 lines · ST
Quoted 35 lines · Chris Murphy
Quoted 34 lines · ST
Quoted 33 lines
Quoted 20 lines
Quoted 20 lines
Quoted 8 lines
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"Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 15 lines
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.
Quoted 7 lines
Quoted 2 lines
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!
Quoted 73 lines · ST
Quoted 69 lines · Qu Wenruo
Quoted 56 lines · ST
Quoted 35 lines · Chris Murphy
Quoted 34 lines · ST
Quoted 33 lines
Quoted 20 lines
Quoted 20 lines
Quoted 8 lines
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"Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 10 lines
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)?Quoted 8 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 2 lines
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
Quoted 7 lines
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!