----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/44948/#review126613 -----------------------------------------------------------
src/slave/containerizer/mesos/isolators/disk/xfs.cpp (lines 501 - 503) <https://reviews.apache.org/r/44948/#comment189628> Chatted offline. Feels like the right thing to do here is to treat a container with no disk resource as `limit == 0`, whether the container started with zero disk resource or is updated to zero. Given XFS' lack of ability to enforce disk quota below a basic block (512bytes), I think it's OK to do so and in the user doc make it clear that "with XFS isolator when no disk resource or zero disk resource is given, XFS will limit it at 512bytes (the size of a basic block)." In fact, XFS cannot do enforcement at a granularity below 512bytes. However since Mesos' disk resource granularity is more coarse than it (at 1KB, or 0.001 of 1MB), this shouldn't violate any expectations. Given that this is a pretty strict behavior (in most cases the task will fail immediately because of stdout/stderr/downloads) I think we should act this way based on a flag, maybe only if `flags.enforce_container_disk_quota == true`, but it raises another question of whether XFS isolator should support monitoring-only mode. Therefore I think it can be punted to a later review, I'll raise a JIRA intead. - Jiang Yan Xu On March 31, 2016, 5:01 p.m., James Peach wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/44948/ > ----------------------------------------------------------- > > (Updated March 31, 2016, 5:01 p.m.) > > > Review request for mesos, Jie Yu and Jiang Yan Xu. > > > Bugs: MESOs-4828 > https://issues.apache.org/jira/browse/MESOs-4828 > > > Repository: mesos > > > Description > ------- > > Track sandbox directory usage by dynamically assigning XFS project > quotas. We track a range of XFS project IDs, assigning a project ID > and a project quota to each sandbox as it is created. When the task > reaches the quota, writes will fail with EDQUOT, and the task will have > an opportunity to handle that. > > Quotas are not applied to volume resources since the isolator interface > has no insight into the volume lifecycle. Thus it is not currently > possible to accurately assign and reclaim project IDs. > > If LOW is the lower bound of the project ID range and HIGH is the upper > bound, you can show the currently allocated project quotas using the > xfs_quota command: > > $ xfs_quota -x -c "report -a -n -L LOW -U HIGH" > > To show the project ID assigned to the file PATH, use the xfs_io command: > > $ xfs_io -r -c stat PATH > > > Diffs > ----- > > src/Makefile.am f22ae5b3bd9336a56c802e0e51d39d6cb675caf2 > src/slave/containerizer/mesos/containerizer.cpp > a5dd22380066aa85de04d485052084e2629681c0 > src/slave/containerizer/mesos/isolators/xfs/disk.hpp PRE-CREATION > src/slave/containerizer/mesos/isolators/xfs/disk.cpp PRE-CREATION > src/slave/containerizer/mesos/isolators/xfs/utils.hpp PRE-CREATION > src/slave/containerizer/mesos/isolators/xfs/utils.cpp PRE-CREATION > src/slave/flags.hpp d0c606eea74e1a2e69067c43a267047e65a22a04 > src/slave/flags.cpp 0551ec334c6747507bf7bb068d27d67f3fdd6c83 > > Diff: https://reviews.apache.org/r/44948/diff/ > > > Testing > ------- > > Make check. Manual testing. Tests in subsequent patches. > > > Thanks, > > James Peach > >
