Re: [RFC] support multiple max offset limits for a single superblock
On Fri, Nov 30, 2007 at 10:35:01AM -0600, Eric Sandeen wrote: I could do the same for ext4, but Chris Mason prodded me to think of something more generic... this is what I came up with. I think it (for now) should remain in the few file-systems that are affected to avoid making a new -i_op right now. If it turns out this is a more commonly need in the future we could do this, but it seems a bit heavy handy just yet given at present. Also, it might turn at that it makes sense to to on-the-fly conversion in the filesystem (where applicable) at some later stage, so this wouldn't be useful there. I assume it's probably hard to convert a large bitmap-based ext4 file to an extent-based one (how large can a transaction be?) but that might not always be the case and it's probably fine for smaller files. (BTW another option would be to convert old-format files when accessed, but that has its own set of tradeoffs...) I think doing that where possible makes more sense. As I said above I'm not sure how easy that is to do for all files, but then again fsck could take care of those if prodded. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] fallocate system call
On Mon, Apr 30, 2007 at 03:56:32PM +1000, David Chinner wrote: On Sun, Apr 29, 2007 at 10:25:59PM -0700, Chris Wedgwood wrote: IIRC, the argument for FA_ALLOCATE changing file size is that posix_fallocate() is supposed to change the file size. But it's not posix_fallocate; it's something more generic. glibc can do posix_fallocate using truncate + fallocate. Note that the way XFS implements growing the file size after the allocation is via a truncate What's wrong with that? That seems very reasonable. That's would what I did because otherwise you'd use ftruncate64(). Without documented behaviour or an ext4 implementation, I have to ask what it's supposed to do, though ;) How many *real* users are there for ext4? Why does 'what ext4 does' define 'the semantics'? Surely semantics should be decided either by precedent (if there is an existing relevant userbase) or sensible thought and some debate? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] fallocate system call
On Mon, Apr 30, 2007 at 10:47:02AM +1000, David Chinner wrote: For FA_ALLOCATE, it's supposed to change the file size if we allocate past EOF, right? I would argue no. Use truncate for that. For FA_DEALLOCATE, does it change the filesize at all? Same as above. Or does it just punch a hole in the file? Yes. FWIW, we definitely need a FA_PREALLOCATE mode (FA_ALLOCATE but does not change file size) so we can preallocate beyond EOF for apps which use O_APPEND (i.e. changing file size would cause problems for them). FA_ALLOCATE should be able to allocate past-EOF I would argue. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] fallocate system call
On Fri, Apr 27, 2007 at 07:46:13PM +0200, Heiko Carstens wrote: If one insists to have fd at first argument, what is wrong with having u32 arguments only? Well, I was one of those who objected as it seems *UGLY* to me. It's not that this syscall comes even close to what can be considered performance critical... Right. It adds userspace overhead for one architecture. Every *trace and *libc needs special handling on s390 for this syscall. I would prefer to avoid this. I'm not that bothered about it. I would prefer it did use clean 64-bit arguments, but given it's a non-critical syscall I'm don't think the aesthetics are worth impossing crud on s390 for. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interface for the new fallocate() system call
On Thu, Mar 29, 2007 at 05:21:26PM +0530, Amit K. Arora wrote: int fallocate(int fd, loff_t offset, loff_t len, int mode) Right now there are only two possible values for mode --- it's not clear what additional values there will be in the future. How about two syscalls? If we decide later on we need something more complicated we can revisit this and *THEN* add another system call which may end up being a superset of the other two. I know that sounds somewhat icky but: * it's fairly simple * we get nice argument handling on all arches by dropping u32 mode (don't we?) * syscalls don't really cost a lot to keep about, they do cost in terms on maintenance though, but in this case i don't see it being all that much of a problem * IMO badly/over designed syscalls are going to be a bigger problem long term Given that *NO* single fs in mainline right now can *reliably* use this functionality for a while maybe whatever solution people come up with next should sit in -mm for a while? At least that gives people exposure to it and a chance to make some changes as once it's merged to mainline it's pretty hard to change. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] sys_fallocate() system call
I hate to comment at this late stage, especially on something that I think is really a great idea (I did similar more complex, sys_blkalloc with even more arguments time ago --- I'm glad given how complex this thread has become I didn't post them now). In the past there wasn't that much incentive to get this functionality exposed because of various other issues (mmap + page dirty didn't flush reliably) which are close to being resolve, so I think the timing of this is really great On Wed, Mar 21, 2007 at 05:34:25PM +0530, Amit K. Arora wrote: As suggested by you and Russel, I have made this change to the patch. Here is how it looks like now. Please let me know if anyone has concerns about passing arguments this way (breaking each loff_t into two u32s). I really dislike breaking 64-bit args up unless it's necessary. I guess it doesn't really hurt, but it feels needlessly ugly. + .long sys_fallocate /* 320 */ +/* + * fallocate() modes + */ +#define FA_ALLOCATE 0x1 +#define FA_DEALLOCATE0x2 + given there are the only TWO modes right now, why not leave the arguments as 64-bit sane and simply have two syscalls, one for each? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: impact of 4k sector size on the IO FS stack
On Tue, Mar 13, 2007 at 01:11:44AM -0400, Andreas Dilger wrote: I'd guess a vast majority of IO will have the end similarly misaligned as the start. Very little filesystem IO is 512 bytes, possibly excluding XFS in an unusual mode. XFS (mkfs.xfs) can be told what the native sector size is and will adjust writes accordingly. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add file position info to proc
On Sat, Mar 10, 2007 at 03:02:22PM +0100, Jan Engelhardt wrote: http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg03964.html to make 'lsof -o' work/happy? is that really worth it? we've managed without it for years... i'n not entirely against the concept, i just work that we too easily add things to /proc and hence it's the mess it is now - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add file position info to proc
On Fri, Mar 09, 2007 at 02:54:38PM +0100, Miklos Szeredi wrote: This patch adds support for finding out the current file position, open flags and possibly other info in the future. who needs this? /proc/ is an ugly beast at the best of times, is this really needed? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: end to end error recovery musings
On Fri, Feb 23, 2007 at 09:32:29PM -0500, Theodore Tso wrote: And having a way of making this list available to both the filesystem and to a userspace utility, so they can more easily deal with doing a forced rewrite of the bad sector, after determining which file is involved and perhaps doing something intelligent (up to and including automatically requesting a backup system to fetch a backup version of the file, and if it can be determined that the file shouldn't have been changed since the last backup, automatically fixing up the corrupted data block :-). i had a small c program + perl script that would take a badblocks list and figure out which files on an xfs filesystem were trashed, though in the case of xfs it's somewhat easier because you can dump the extents for a file something more generic wouldn't be hard to make work, it also wouldn't be hard to extend this to inodes in some cases though im not sure that there is much you can do there beyond fsck - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
