On Fri, Mar 4, 2016 at 6:40 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Thu, Mar 03, 2016 at 03:08:22PM +0100, Arnd Bergmann wrote: >> On Thursday 03 March 2016 10:45:11 Dave Chinner wrote: >> > On Thu, Mar 03, 2016 at 12:07:42AM +0100, Arnd Bergmann wrote: >> > > On Thursday 03 March 2016 09:19:05 Dave Chinner wrote: >> > > > On Wed, Mar 02, 2016 at 07:51:34AM -0800, Deepa Dinamani wrote: >> > > > > --- a/include/linux/fs.h >> > > > > +++ b/include/linux/fs.h >> > > > > @@ -927,6 +927,12 @@ static inline struct file *get_file(struct file *f) >> > > > > #define MAX_LFS_FILESIZE ((loff_t)0x7fffffffffffffffLL) >> > > > > #endif >> > > > > >> > > > > +#define MAX_VFS_TIME S64_MAX >> > > > > +#define MIN_VFS_TIME S64_MIN >> > > > >> > > > These. Anything ouside these ranges is invalid. >> > > > >> > > > As such, I think this is wrong for 32 bit systems as the min/max VFS >> > > > times right now are S32_MAX/S32_MIN... >> > > >> > > I think the file system should always set the actual on-disk format >> > > limits in the superblock, regardless of the word size of the CPU >> > > architecture. >> > >> > Eventually, yes. But right now, 32 bit systems are limited by the >> > platform architecture. Hence no matter what the filesystem on-disk >> > format supports, these are going to hard limits until filesystems >> > start modifying the defaults to indicate what their on-disk format >> > supports. >> >> The purpose of the patch for now is to allow file systems to set >> the defaults, we are not checking them yet, until all file systems >> are converted, hence setting the defaults to invalid. > > Wrong way around, IMO. Set the defaults to be limiting first, then > as filesystems are converted the limits get expanded. The picture is not clear until you see how we use these values and these are just values until then. You should be able to get a better picture on what we are trying to do and the discussion makes more sense when we post the patches that use these. We are just trying to get some initial infrastructure so that we can proceed to post the subsequent patches. Here are the approaches that were considered and why this one was picked: Approach 1 Use default values in the vfs layer This was the first version considered (Arnd has a patch from me). Steps involved: a. Use default values to initialize limits in alloc_super() b. implement vfs policy c. Each filesystem chooses to fill in their actual values, at its own pace. d. Initialize to invalid defaults in vfs. Cons: a. There are unmaintained filesystems that will never be changed. b. What about the filesystems that support ranges lesser than S32_MAX and greater than S32_MIN Eg: ceph, fat, iso9660? vfs policies will not be safe here. c. wherever these values are clamped, it will lead to changing every filesystems twice, before and after right limits are filled in. Approach 2 Use invalid values in the vfs layer. Steps involved: a. Use invalid values to initialize limits in alloc_super() b. implement vfs policy, but only limit to filesystems which fill in actual range. c. We change each filesystem to fill in their actual values. d. Maybe make compulsory to have a valid range, according to policy chosen. This approach was chosen because it is clear with this approach as it addresses all the cons in approach 1. -Deepa -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
