Chris Murphy <li...@colorremedies.com> schrieb: > > On Feb 6, 2014, at 11:08 PM, Roman Mamedov <r...@romanrm.net> wrote: > >> And what >> if I am accessing that partition on a server via a network CIFS/NFS share >> and don't even *have a way to find out* any of that. > > That's the strongest argument. And if the user is using > Explorer/Finder/Nautilus to copy files to the share, I'm pretty sure all > three determine if there's enough free space in advance of starting the > copy. So if it thinks there's free space, it will start to copy and then > later fail midstream when there's no more space. And then the user's copy > task is in a questionable state as to what's been copied, depending on how > the file copies are being threaded.
This problem has already been solved for remote file systems maybe 20-30 years ago: You cannot know how much space is left at the end of the copy by looking at the numbers before the copy - it may have been used up by another user copying a file at the same time. The problem has been solved by applying hard and soft quotas: The sysadmin does an optimistic (or possibly even pessimistic) planning and applies quotas. Soft quotas can be passed for (maybe) 7 days after which you need to free up space again before adding new data. Hard quotas are the hard cutoff - you cannot pass that barrier. Df will show you what's free within your softquota. Problem solved. If you need better numbers, there are quota commands instead of df. Why break with this design choice? If you manage a central shared storage for end users, you should really start thinking about quotas. Without, you cannot even exactly plan your backups. If df shows transformed/guessed numbers to the sysadmins, things start to become very complicated and unpredictable. -- Replies to list only preferred. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
