No - not a fan of adding more random policies.  We definitely don't need a policy to have some admin change it from 1 GB to 5 GB or whatever they choose - 99% of admins will have almost no idea why this exists and it doesn't need to exist.  The correct bug fix is to report back to apps correctly the actual amount of disk space left when you include removing of other partition data.  That solves all issues correctly, silently, and doesn't bloat our admin console with another nonsense bug.

Fukino, can what cyrusm@ suggest be done within a session?

I suppose it's difficult.
Calculating other user's directory size can take 1 minute or more when the user has huge number of files.
Doing the calculation on every query about the disk space or caching/updating the size in enough interval will have considerable performance overhead.

fukino@ - couldn't we do a check of other user's directory size only once upon login (in background), so that way even if it takes 1 minute we have all sizes in LRU order and can easily remove as space is needed vs. doing a query each time?  Given other user directory sizes won't change once the user has logged in, we don't need to query each time, right?

Also, 1 minute to calculate total space for each partition seems astronomical.  Any way to optimize that?

And, lastly, I wonder if there is a simpler proxy calculation we could do - e.g. total disk size of system minus size of current partition minus normal overhead space needed for OS (including some buffer in case there is OS bloat over time) should give how much space could be gained by removing all the other user directories?

Open to creative ideas. :)

Hi Cyrus,

I have a few concerns about calculating other user's directory size on sign in.
- Other user's directory size can change by automatic cache removal on low-space situation. (other example is when another user sign-in and sign-out using multiple sign-in).
- It might slow down the system after boot (even when it's running on background, I guess)

Regarding the calculation cost, each user data is stored in an encrypted directory, not a partition. That's why we can't user more effective method like statvfs and need to sum up file sizes recursively. We are doing basically the same as du command, so I don't see an easy way to optimize it further for now.

I have an another concern. Can we remove other profiles silently? (+mitsuji@ for this point)
It should be OK on shared Chromebooks in schools, but the data loss by profile removal can be serious in family use etc.
I think that a policy to prioritize current user's storage demand over other users' data makes sense here.

My rough idea is that we remove all other users on sign-in when the policy above is enabled.
If there is only the current user, we don't need to sum up the other user's size or remove it dynamically. The signed-in user always have enough disk space.
The current default behavior (keeping 512MB by removing LRU users) should work in most cases, but in a situation that each user need more empty space to work, the policy above might be helpful.
WDYT?

Do we currently report back (via UMA or otherwise) how often we remove older partitions due to the 512GB default we have now?  How would that number change if we changed it to 1GB as the default?  Let's compare that to how often does the current user run out of disk space with the 512GB current default.  That way we can make the right product decision.  We should try to choose the right default based on real data.  I'm not a fan of throwing this problem to the admin without the admin having this data themselves - so before we do that or add any other policies, can we see the data?

Thanks!

512 Mb rather?

Would be great to get a PM owner that can help refine requirements, etc. Who on the PM side can help drive this? Max? David? Naveen?

Discussed with zelidrag@" Yes, we need a policy. The policy should at least control if profile nuking is allowed.

Hi Alexey,

Sorry - can you elaborate.  You discussed what with Zel? You need a policy for what?  Why would we need a policy to control if profile nuking is allowed since it's LRU profiles have been removed for years in the background.

Also, before we do anything, please respond to comment 11.

Re #11: No, we don't have any UMA for old user profiles deletion. I want to add an UMA as a part of https://bugs.chromium.org/p/chromium/issues/detail?id=835114 

Re #11: Cryptohome.DeletedUserProfiles added. Wait for M68.