Re: [RFC] ext3 freeze feature
On Friday 25 January 2008 05:33, Theodore Tso wrote: > and then detect the > deadlock case where the process holding the file descriptor used to > freeze the filesystem gets frozen because it attempted to write to the > filesystem --- at which point it gets some kind of signal (which > defaults to killing the process), and the filesystem is unfrozen and > as part of the unfreeze you wake up all of the processes that were put > to sleep for touching the frozen filesystem. Hi Ted, There are a few holes: * The process may try to handle the signal and end up blocking on the filesystem again. * The process might pass the fd to another process by forking or fd passing. * The process holding the fd might be trying to take a lock held by another process that is blocked on the filesystem, and infinite variations on that theme. Remembering the task that did the ioctl might work out better than remembering the fd. Or just not try to be so fancy and rely on the application to take appropriate measures to ensure it will not access the filesystem, such as memlocking and not execing. The freezer also needs to run in PF_MEMALLOC mode or similar unless it can be sure it will not cause pageout to the frozen filesystem under low memory conditions. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm patch]
On Sunday 20 January 2008 18:51, Theodore Tso wrote: > On Sat, Jan 19, 2008 at 08:10:20PM -0800, Daniel Phillips wrote: > > I can see value in preemptively loading indirect blocks into the > > buffer cache, but is building a second-order extent tree really > > worth the effort? Probing the buffer cache is very fast. > > It's not that much effort, and for a big database (say, like a 50GB > database file), the indirect blocks would take up 50 megabytes of > memory. Collapsing it into an extent tree would save that memory > into a few kilobytes. I suppose a database server would probably > have 5-10GB's of memory, so the grand scheme of things it's not a > vast amount of memory, but the trick is keeping the indirect blocks > pinned so they don't get pushed out by some vast, gigunndo Java > application running in the same server as the database. If you have > the indirect blocks encoded into the extent tree, then you don't have > to worry about that. Hi Ted, OK I think you are right, because this is a nice step towards developing an on-disk extent format for Ext4 that avoids committing design mistakes to permanent storage. The benefit can be proven using a pure cache, in order to justify the considerable work necessary to make it persistent. Chris and Jens have an effort going to implement a physical disk extent cache for loop.c. It is actually the same problem, and I smell a library here. Issue: how do you propose to make this cache evictable? Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm patch]
On Thursday 17 January 2008 04:47, Abhishek Rai wrote: > > if Abhishek wants to pursue it, would be to pull in all of the > > indirect blocks when the file is opened, and create an in-memory > > extent tree that would speed up access to the file. It's rarely > > worth doing this without metaclustering, since it doesn't help for > > sequential I/O, only random I/O, but with metaclustering it would > > also be a win for sequential I/O. (This would also remove the > > minor performance degradation for sequential I/O imposed by > > metaclustering, and in fact improve it slightly for really big > > files.) > > Also, since the in memory extent tree will now occupy much less > space, we can keep them cached for a much longer time which will > improve performance of random reads. The new metaclustering patch is > more amenable to this trick since it reduces fragmentation thereby > reducing the number of extents. I can see value in preemptively loading indirect blocks into the buffer cache, but is building a second-order extent tree really worth the effort? Probing the buffer cache is very fast. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm patch]
On Tuesday 15 January 2008 03:04, Andrew Morton wrote: > I'm wondering about the real value of this change, really. > > In any decent environment, people will fsck their ext3 filesystems > during planned downtime, and the benefit of reducing that downtime > from 6 hours/machine to 2 hours/machine is probably fairly small, > given that there is no service interruption. (The same applies to > desktops and laptops). > > Sure, the benefit is not *zero*, but it's small. Much less than it > would be with ext2. I mean, the "avoid unplanned fscks" feature is > the whole reason why ext3 has journalling (and boy is that feature > expensive during normal operation). > > So... it's unobvious that the benefit of this feature is worth its > risks and costs? Since I am waiting for an Ext3 fsck to complete right now, I thought I would while away the time by tagging on my "me too" to the concensus that faster fsck is indeed worth the cost, which is (ahem) free. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
