Re: [PoC 0/7] Kobjectify filesystem

From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: Viacheslav Dubeyko <slava@dubeyko.com>
Cc: linux-fsdevel@vger.kernel.org, Goldwyn Rodrigues <rgoldwyn@suse.com>
Subject: Re: [PoC 0/7] Kobjectify filesystem
Date: Fri, 29 Apr 2016 13:28:00 -0500	[thread overview]
Message-ID: <5723A7B0.9080901@suse.de> (raw)
In-Reply-To: <1461951179.2619.5.camel@slavad-ubuntu-14.04>

On 04/29/2016 12:32 PM, Viacheslav Dubeyko wrote:
> Hi Goldwyn,
>
> On Thu, 2016-04-28 at 21:01 -0500, Goldwyn Rodrigues wrote:
>> From: Goldwyn Rodrigues <rgoldwyn@suse.com>
>>
>> This is an effort to represent fs structures in terms of kobjects.
>>
>> The primary goal of this was to provide a mechanism for the filesystems
>> to provide feedback to userspace but grew more than that.
>> In case of errors  users may fix errors and could schedule a
>> complete filesystem check at a later point of time.
>> ENOSPC errors could be automated to delete temporary files
>> etc.
>>
>> As a implementation example, I have changed ocfs2 to support the change,
>> though it is not completely feasible change because of the way ksets are
>> represented in kset, but it delivers the idea.
>>
>> Taking this forward may reduce the house-keeping tasks such as searching,
>> list handling and locking. One example shown here is the super_block
>> destruction using kobjects. Since most filesystems do represent their
>> structures in sysfs, this would consolidate individual representations
>> under the filesystem, hopefully reducing code.
>>
>> Let me know what you think about the idea.
>>
>
> You can register any attributes in sysfs. So, what do you suggest
> finally? What common scheme for all file systems do you suggest to use?
> Suppose, I didn't catch the idea. Did you invent sysfs itself? Could you
> describe your vision more clearly? The idea looks obscure right now,
> from my point of view.
>

Yes, you can register any attribute to sysfs, and most filesystems are 
doing exactly that. They maintain the kobject in their <fs>_super_block 
struct and use it to create /sys/fs/<fstype>/<id> entries. So what I 
propose is this:

1. Move the kobject to super_block from individual filesystem's 
super_block structs and institute it when the filesystem mounts. We 
could use explicit flags if filesystems choose not to use this "feature" 
and do it on their own.

2. Add a kset to files_system_type to create the /sys/fs/<fstype> entry. 
Again, most filesystems are doing this anyways.

3. Provide super_block_attribute structures if filesystems want to 
export their filesystem attributes via sysfs. Individual filesystems 
would have to write their own <name>_store() and <name>_show() functions 
to describe how/what they want to export the values. These are purely 
helping functions.

4. (Primary objective: Improve availability of filesystems) Use the 
kobject in the super_block to generate filesystem uevents which could be 
used to communicate errors. The idea was to provide an option of 
errors=continue in filesystems so filesystems continue in case of 
errors. While the process encountering the error will be terminated with 
say an EIO, however an error-code is also delivered through uevent which 
can be picked up by udev scripts. Since the filesystem module is also 
listed, each individual filesystems should come out with a utility to 
fix the problem while the filesystem is online at best-effort ability. 
Or could take backups or inform the administrator etc.
For a fix, the uevent would deliver the necessary information, say the 
inode number or file path, which could be used to fix this. The 
filesystem utility would use this to fix the error online. Once fixed, 
the program which caused the error can be restarted. Other possible 
errors are ENOSPC being interrupt based as opposed to poll based 
applications which exist today.
Currently, ocfs2 performs an online fix, albeit at a basic inode block 
level. You write the faulty inode number into a sysfs file and it tries 
to fix inode block.
Please note, this is a trade-off between availability and 
consistency/integrity in the system. While such a system would keep the 
system alive and running at peak hours, a complete fsck may still be 
required when the administrators are more at peace (off-peak hours)

-- 
Goldwyn