Re: [PATCH 0/2] make automatic device_id generation possible

[Minchan Kim]

On Thu, Mar 05, 2015 at 10:47:52AM +0900, Sergey Senozhatsky wrote:
> On (03/05/15 10:33), Minchan Kim wrote:
> > > hm, I can think of a huge build server with tons of users. /dev/zram$(id -u)
> > > created during user login and destroyed during logout. so users use theirs own
> > > zram devices with predictable device ids (which also makes it simpler for admin)
> > > for compilation/etc., and don't pressure hdds that much.
> > 
> > They upgraded the system and from now on, one of app tries automatic
> > id with zram for some reason. What happens if he gets some user id
> > before the user login? The system should have fallback in the case of
> > failing to create own userid assignment.
> 
> we upgraded our scripts but landed some bugs there? it's up to particular
> implementation. in your example, I assume, someone used zram with num_devices >= 1000?
> that's impossible. current num_devices limitation is 32. and uid-s start from 1000.

I meant it.
If we support use-defined id and someone have used your idea so he can make zram
per-user as uid. After a while, new application stats automatic id assignment
so upcoming users can consume upcoming user id. yeah, automaic id will start
from 0 so it's very rare to reach 1000 but who knows?
My point is in your usecase, the script would be very fragile so it should
have second plan like automatic id. 

> 
> these scripts should check if device has been created anyway, it just adds -EEXIST
> check. in general "what if user space does something wrong" thing can be beaten by
> "what if user space does everything right" argument. when script fails we just go
> and fix that script, I guess.

Yes, I believe finally the script will go automatic id if it was broken.
So, why does we should support user-defined id if they finally should
turn around from user-defined to automatic?


> 
> 	-ss
> 
> > 
> > Hmm, Coexisting specific and automatic id assign seem to be not a
> > godd idea.

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/