> > > One part of the design which you didn't describe, but which I inferred > > > is that you intend that userspace will see the FS_UNCLEAN=1 messages > > > and will then poll all the /sys/block/<bdev>/<part>/fs_unclean files to > > > work out which partition(s) got the error, correct? Please spell all > > > that out in the changelog. > > > > I think this part of the design needs more thought. Not > > all FSes have block devices (UBIFS, JFFS2), and some FSes > > may (theoretically) span more than one block device (btrfs?). > > Big thanks to everybody participating in this thread, for reviews and critiques. > Here's a proposal/RFC for another way to implement this feature: > > Taking into account Artem's and Kay's comments, indeed, having attributes > like 'fs_error' tied to a block device does not seem right. > What we need is an object/entity that: > > - is not associated to a block device > - is not associated to a partition > - is not associated to a filesystem as a general entity > - is uniquely associated to a filesystem's 'instance': a mounted volume > carying that filesystem > - apperas at volume mount time and disappears with volume unmount Add a ",errors " at the end of line to /proc/mounts when error is detected? (...and make /proc/mounts pollable?) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
