You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, this can happen at the OS level, at the node application level, or with a process sitting in the middle. A combination of 3 of these can happen too.
We should perhaps work on some generic helper scripts to analyze existing pods, in a way that gives a sys admin the stats they need, without compromising any user privacy.
Starting on this now, but since we are now just doing urgent things, my plan is to record a quota in the users database, and find something that works like UNIX du, and show the user a bar with their allowance, and then do something in the write operations to stop them from exceeding it.
Note : it doesnt have to be STORED in RDF, but it can still be modeled in RDF.
Yeah I guess we have a posix vocab already, I wonder if there's something reusable there like blocks. Getting down to the byte level would be cool, but how wide is the int that stores it?
Yeah, but I figured if is stored as RDF, I can do it right away, otherwise you'd need to file a feature request. :-)
So, the obvious place to store it in the current arch is in the users part of the key-value store and implement it in the UserAccount class, which is what I started doing. But it is certainly also an option to store in a file in settings along with prefs.ttl et al... I don't know what would be involved to do that, but I'll check it out. I hope you don't mind me taking the path of least resistance right now :-) That path will not be taken frequently, once we get head above water.
I hope you don't mind me taking the path of least resistance right now
Of course!
Any future unexpected reuse is a bonus.
I suggest writing out the design before diving in, would be useful.
So, the obvious place to store it in the current arch is in the users part of the key-value store and implement it in the UserAccount class, which is what I started doing
Yes, so we need an ephemeral value showing how much disk is left.
And we need either a server wide quota limit, or a per user quota limit, or a default than can be upped (say for different tiered usage)
Just sprung to mind. @megoth did a cool thing yesterday where he created a file that he could read, but not write to (in his own space). Perhaps this is the path to creating system files.
We have a file in /profile/ something like quota.ttl and set the acl to read only so only the system can write to it. Just an idea (thinking outside the box).
Does it need to be stored in their data space though? We could manage a separate data space where system-controlled data are stored, couldn't we? Just so that we don't mix system-controller and user-controller files.
Yeah I guess we have a posix vocab already, I wonder if there's something reusable there like blocks. Getting down to the byte level would be cool, but how wide is the int that stores it?
Something I've learned while putting Gentoo on a Raspberry Pi: There's aa difference between size (in bytes) and number of inodes (in an ext4 filesystem).
That is, du (iirc) can still report free space while du -i tells you that your disk is full. I can look up details if you need. Maybe another issue? :-)
Activity
melvincarvalho commentedon Oct 4, 2018
So, this can happen at the OS level, at the node application level, or with a process sitting in the middle. A combination of 3 of these can happen too.
We should perhaps work on some generic helper scripts to analyze existing pods, in a way that gives a sys admin the stats they need, without compromising any user privacy.
melvincarvalho commentedon Oct 4, 2018
Examples
A script to find out the number of accounts on a pod.
A script to find out the total, mean, median, min and max disk usage on a pod, without revealing the username
A script to count the number of accounts above accounts above a certain quota
This could lead to setting sensible limits, based on the server capabilities, and leading to defaults that can be communicated to the user.
In a previous system, we had a little bar on the dashboard, showing your total disk allowance, and how full you are. That could work quite well.
kjetilk commentedon Oct 17, 2018
Starting on this now, but since we are now just doing urgent things, my plan is to record a quota in the users database, and find something that works like UNIX
du, and show the user a bar with their allowance, and then do something in the write operations to stop them from exceeding it.melvincarvalho commentedon Oct 17, 2018
And excellent start. Can we do this in RDF?
csarven commentedon Oct 17, 2018
One way to generalise this issue would be to have server-centric resources that can include desired content.
kjetilk commentedon Oct 17, 2018
Oh, yes, @csarven . But right now, we're not looking to generalize, that's for later, we're just fighting fires now :-)
kjetilk commentedon Oct 17, 2018
Let me see, @melvincarvalho !
melvincarvalho commentedon Oct 17, 2018
Could be roughly what we need.
It's also close to how I've modeled payments, so we could at some point integrate payemnts and quotas, is why I ask ...
EDIT : our previous PHP servers had a working quota bar on the user dashboards, so that might provide some insights.
kjetilk commentedon Oct 17, 2018
Ah, great!
But that should not be writeable to the user, so where do I store it? Somewhere in settings, with an ACL that grants only read access?
But how we go for MBs as the smallest unit of quota?
melvincarvalho commentedon Oct 17, 2018
@kjetilk where is user specific stuff written?
Note : it doesnt have to be STORED in RDF, but it can still be modeled in RDF.
Yeah I guess we have a posix vocab already, I wonder if there's something reusable there like blocks. Getting down to the byte level would be cool, but how wide is the int that stores it?
kjetilk commentedon Oct 17, 2018
Yeah, but I figured if is stored as RDF, I can do it right away, otherwise you'd need to file a feature request. :-)
So, the obvious place to store it in the current arch is in the
userspart of the key-value store and implement it in theUserAccountclass, which is what I started doing. But it is certainly also an option to store in a file in settings along with prefs.ttl et al... I don't know what would be involved to do that, but I'll check it out. I hope you don't mind me taking the path of least resistance right now :-) That path will not be taken frequently, once we get head above water.melvincarvalho commentedon Oct 17, 2018
Of course!
Any future unexpected reuse is a bonus.
I suggest writing out the design before diving in, would be useful.
Yes, so we need an ephemeral value showing how much disk is left.
And we need either a server wide quota limit, or a per user quota limit, or a default than can be upped (say for different tiered usage)
melvincarvalho commentedon Oct 17, 2018
Just sprung to mind. @megoth did a cool thing yesterday where he created a file that he could read, but not write to (in his own space). Perhaps this is the path to creating system files.
We have a file in /profile/ something like quota.ttl and set the acl to read only so only the system can write to it. Just an idea (thinking outside the box).
melvincarvalho commentedon Oct 17, 2018
profileprobably the wrong place for it`maybe
.systemor.well-known/solid/kjetilk commentedon Oct 17, 2018
Yes, that was what I had in mind. But settings seems even better.
So, I found the posix-stat, which has size, but I would have preferred a datatype, e.g.
dmitrizagidulin commentedon Oct 17, 2018
That seems.. problematic :) Are we really going to store files over which the user has no control, in their data space, DRM-style?
dmitrizagidulin commentedon Oct 17, 2018
Hmm. On second thought, I guess we do need to store system-controlled data eventually. (To record the author, access logs, etc.) Never mind :)
megoth commentedon Oct 18, 2018
Does it need to be stored in their data space though? We could manage a separate data space where system-controlled data are stored, couldn't we? Just so that we don't mix system-controller and user-controller files.
kjetilk commentedon Nov 12, 2018
Given the review in #911, this now only relies on solid/vocab#35
Ryuno-Ki commentedon Nov 12, 2018
Something I've learned while putting Gentoo on a Raspberry Pi: There's aa difference between size (in bytes) and number of inodes (in an ext4 filesystem).
That is,
du(iirc) can still report free space whiledu -itells you that your disk is full. I can look up details if you need. Maybe another issue? :-)kjetilk commentedon Nov 15, 2018
That's not necessary. It uses https://www.npmjs.com/package/get-folder-size , we take what we get from there.