Home » Mailing list archives » linux-fsdevel » 2008 » January

linux-fsdevel mailing list

FromSubjectsort iconDate
James Morris
[PATCH][RFC] security: call security_file_permission from rw...
Please review. Tested with SELinux in enforcing mode. --- All instances of rw_verify_area() are followed by a call to security_file_permission(), so just call the latter from the former. Signed-off-by: James Morris <jmorris@namei.org> --- fs/compat.c | 4 --- fs/read_write.c | 63 +++++++++++++++++++++---------------------------------- fs/splice.c | 8 ------- 3 files changed, 24 insertions(+), 51 deletions(-) diff --git a/fs/compat.c b/fs/compat.c index 15078c...
[ message continues ]
Jan 12, 7:20 am 2008
Al Boldi
Re: [RFD] Incremental fsck
Don't mistake data=journal as an fsck replacement. Thanks! -- Al -
Jan 12, 6:20 am 2008
Daniel Phillips
Re: [RFD] Incremental fsck
You can do this now with ddsnap (an out-of-tree device mapper target) either by checking a local snapshot or a replicated snapshot on a different machine, see: http://zumastor.org/ Doing the check on a remote machine seems attractive because the fsck does not create a load on the server. Regards, Daniel -
Jan 12, 7:55 pm 2008
Theodore Tso
Re: [RFD] Incremental fsck
After a unclean shutdown, assuming you have decent hardware that doesn't lie about when blocks hit iron oxide, you shouldn't have any So what can you check? The *only* thing you can check is whether or not the directory syntax looks sane, whether the inode structure looks sane, and whether or not the blocks reported as belong to an inode looks sane. What is very hard to check is whether or not the link count on the inode is correct. Suppose the link count is 1, but there are actually two dir...
[ message continues ]
Jan 12, 10:51 am 2008
Oleg Drokin
Re: Leak in nlmsvc_testlock for async GETFL case
Hello! After playing around that code a bit more, I figured out the leak was not completely fixed by that first patch, the case where there is conflicting lock passed in by callback still leaks block reference. This simple incremental fix (against your current tree) takes care of that. Signed-off-by: Oleg Drokin <green@linuxhacker.ru> I guess there is no way to safely include patches in messages in apple mail, so the patch is still attached.
Jan 11, 10:57 pm 2008
previous daytodaynext day
January 11, 2008January 12, 2008January 13, 2008