On Mon 02-03-15 10:53:36, Ted Tso wrote: > > Looking at the Vault schedule, it looks like the best time to schedule > the ext4 developer's workshop will be Wednesday from noon to 3pm (we'll > meet for lunch and then continue until Jan Kara's ext4 file system > scalaing talk. > > And then we can pick up Thursday morning starting at 10am and go on > until Lunch. (Or we could start at 9am and skip the Sasha Levin's file > system fuzzing talk, but I suspect some people wouldn't want to miss > Sasha's talk.) > > Does that work for everyone? > > Things which I expect will be on the schedule include: > > * ext4 encryption progress report (Michael Halcrow, Ted) > * making ext4 smr friendly (Abutalib, Peter, Ted, Tim, Adrian) > * improving the ext4 block allocator (Jun He) > > Since Jaeguk probably would only be interested in the encryption > discussions, I'm going to suggest that we schedule the encryption > discussions for Thursday morning, and the SMR discussions for Wednesday > afternoon, since our minds will be fresh immediately after the SMR > discussions on Thursday morning. > > What other topics would people like to include? Please suggest them on > this e-mail thread. I have about 4 bugs we have in ext4 that I didn't get to fixing because the fix isn't immediately obvious. Maybe some discussion on these would be useful. The issues I'm aware of are: 1) filling of hole from ext4_page_mkwrite() in nodelalloc mode (or when we are running out of space) can race with DIO read of the same location resulting in DIO read returning uninitialized block data (possible security issue). I think using uninitialized extents is the right solution here if we can but what about indirect mapped files (think of ext2 / ext3 compatibility modes)? 2) When doing AIO DIO write we store pointer to ioend structure in the inode. However in dioread_nolock mode, we can run two AIO DIO overwrites in parallel and thus one ioend just overwrites the other resulting in nasty issues. No idea how to best fix this (but I didn't think much about it). 3) inode->i_writecount >= 1 doesn't actually guarantee that ->release() method will be called (as there are places that increase / decrease i_writecount without actually opening the file). Thus we can leave preallocated blocks in an inode. Truncating blocks in ext4_clear_inode() isn't completely reliable since filesystem may be remounted R/O by then. We can create our own writer count but that seems like a bit of an overkill... 4) There's the longstanding issue with punch hole racing with page fault that can lead to stale data exposure or fs corruption. Proper fix in mm is tricky and won't happen soon so should we go the way XFS recently went and just create special locking for that withing ext4? Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
