On Sun, Mar 04, 2007 at 11:22:06PM +, Anton Altaparmakov wrote:
> And I specifically did NOT update the initialized size in the inode
> thus it will remain at its old value thus all new allocated blocks
> will be considered as present but not initialized thus a read will
> always return z
On Mon, Mar 05, 2007 at 07:15:33AM -0800, Ulrich Drepper wrote:
> Well, I'm sure the kernel can do better than the code we have in libc
> now. The kernel has access to the bitmasks which say which blocks have
> already been allocated. The libc code does not and we have to be very
> simple-minded
On Sat, Apr 07, 2007 at 05:44:57PM -0700, [EMAIL PROTECTED] wrote:
> To get a feel for the performance increases that can be achieved by
> using compression, we look at the total time (in seconds) to run the
> test:
You mean the performance increases of writing a file which is mostly
all zero's?
The reason why I ignore the tar+gzip tests is that in the past Hans
has rigged the test by using a tar ball which was generated by
unpacking a set of kernel sources on a reiser4 filesystem, and then
repacking them using tar+gzip. The result was a tar file whose files
were optimally laid out so tha
On Mon, Apr 23, 2007 at 02:53:33PM -0600, Andreas Dilger wrote:
> > With a blocksize of 4KB, a block group would be 128 MB. In the original
> > Chunkfs paper, Valh had mentioned 1GB chunks and I believe it will be
> > possible to use 2GB, 4GB or 8GB chunks in the future. As the chunk size
> > incre
On Mon, Apr 23, 2007 at 06:02:29PM -0700, Arjan van de Ven wrote:
>
> > The other thing which we should consider is that chunkfs really
> > requires a 64-bit inode number space, which means either we only allow
>
> does it?
> I'd think it needs a "chunk space" number and a 32 bit local inode
> nu
On Sat, Apr 28, 2007 at 05:05:22PM -0500, Matt Mackall wrote:
> This is a relatively simple scheme for making a filesystem with
> incremental online consistency checks of both data and metadata.
> Overhead can be well under 1% disk space and CPU overhead may also be
> very small, while greatly impr
On Fri, Apr 27, 2007 at 12:09:42PM -0600, Andreas Dilger wrote:
> I'd prefer that such functionality be integrated with Takashi's online
> defrag tool, since it needs virtually the same functionality. For that
> matter, this is also very similar to the block-mapped -> extents tool
> from Aneesh.
On Sun, Apr 29, 2007 at 08:40:42PM -0500, Matt Mackall wrote:
> chunkfs. The other is reverse maps (aka back pointers) for blocks ->
> inodes and inodes -> directories that obviate the need to have large
> amounts of memory to check for collisions.
Yes, I missed the fact that you had back pointers
On Tue, May 01, 2007 at 12:01:42AM -0600, Andreas Dilger wrote:
> Except one other issue with online shrinking is that we need to move
> inodes on occasion and this poses a bunch of other problems over just
> remapping the data blocks.
Well, I did say "necessary", and not "sufficient". But yes, m
On Tue, May 01, 2007 at 12:52:49PM -0600, Andreas Dilger wrote:
> I think "rm -r" does a LOT of this kind of operation, like:
>
> stat(.); stat(foo); chdir(foo); stat(.); unlink(*); chdir(..); stat(.)
>
> I think "find" does the same to avoid security problems with malicious
> path manipulation.
On Mon, May 07, 2007 at 03:38:56PM -0700, Andrew Morton wrote:
> > Actually, this is a non-issue. The reason that it is handled for
> > extent-only
> > is that this is the only way to allocate space in the filesystem without
> > doing the explicit zeroing. For other filesystems (including ext3 a
On Mon, May 07, 2007 at 07:02:32PM -0400, Jeff Garzik wrote:
> Andreas Dilger wrote:
> >On May 07, 2007 13:58 -0700, Andrew Morton wrote:
> >>Final point: it's fairly disappointing that the present implementation is
> >>ext4-only, and extent-only. I do think we should be aiming at an ext4
> >>bit
On Mon, May 07, 2007 at 05:41:39PM -0700, Mingming Cao wrote:
> We could check the total number of fs free blocks account before
> preallocation happens, if there isn't enough space left, there is no
> need to bother preallocating.
Checking against the fs free blocks is a good idea, since it will
On Mon, May 14, 2007 at 10:35:47PM +0200, Jan Blunck wrote:
>
> I don't know. I tried to contact him a few weeks ago but failed.
> Guess, maybe he isn't reading the @thunk.org email anymore which was
> reference in the e2fsprogs source I used.
I do pay more attention to mail sent to the @mit.edu
On Mon, Jun 04, 2007 at 11:02:23AM -0600, Matthew Wilcox wrote:
> On Mon, Jun 04, 2007 at 09:56:07AM -0700, Bryan Henderson wrote:
> > Programs that assume a full transfer are fairly common, but are
> > universally regarded as either broken or just lazy, and when it does cause
> > a problem, it i
On Mon, Jun 04, 2007 at 08:57:16PM +0200, Roman Zippel wrote:
> That's the last discussion about signals and I/O I can remember:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0208.0/0188.html
Well, I think Linus was saying that we have to do both (where the
signal interrupts and where it doesn't
On Mon, Jun 18, 2007 at 03:45:24AM -0600, Andreas Dilger wrote:
> Too bad everyone is spending time on 10 similar-but-slightly-different
> filesystems. This will likely end up with a bunch of filesystems that
> implement some easy subset of features, but will not get polished for
> users or have a
On Mon, Jun 18, 2007 at 09:16:30AM -0700, alan wrote:
>
> I just wish that people would learn from the mistakes of others. The
> MacOS is a prime example of why you do not want to use a forked
> filesystem, yet some people still seem to think it is a good idea.
> (Forked filesystems tend to be
On Mon, Jun 18, 2007 at 10:33:42AM -0700, Jeremy Allison wrote:
>
> Yeah, ok - but do you have to rub my nose in it every chance you get ?
>
> :-) :-).
Well, I just want to make sure people know that Samba isn't asking for
it any more, and I don't know of any current requests outstanding from
an
On Mon, Jun 18, 2007 at 02:31:14PM -0700, H. Peter Anvin wrote:
> And that makes them different from extended attributes, how?
>
> Both of these really are nothing but ad hocky syntactic sugar for
> directories, sometimes combined with in-filesystem support for small
> data items.
There's a good
On Tue, Jun 19, 2007 at 12:26:57AM +0200, Jörn Engel wrote:
> The main difference appears to be the potential size. Both extended
> attributes and forks allow for extra data that I neither want or need.
> But once the extra space is large enough to hide a rootkit in, it
> becomes a security proble
On Mon, Jun 18, 2007 at 03:48:15PM -0700, Jeremy Allison wrote:
> Did you ever code up forkdepot ? Just wondering ?
There is a partial implementation lieing around somewhere, but there
were a number of problems we ran into that were discussed in the
slidedeck. Basically, if the only program acces
On Thu, Jun 28, 2007 at 11:33:42AM -0700, Andrew Morton wrote:
> > Please let us know what you think of Mingming's suggestion of posting
> > all the fallocate patches including the ext4 ones as incremental ones
> > against the -mm.
>
> I think Mingming was asking that Ted move the current quilt tr
On Fri, Jun 29, 2007 at 10:29:21AM -0400, Jeff Garzik wrote:
> >In any case, the plan is to push all of the core bits into Linus tree
> >for 2.6.22 once it opens up, which should be Real Soon Now, it looks
> >like.
>
> Presumably you mean 2.6.23.
Yes, sorry. I meant once Linus releases 2.6.22, a
On Wed, Jul 04, 2007 at 07:32:34PM +0200, Erik Mouw wrote:
> (sorry for the late reply, just got back from holiday)
>
> On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote:
> > As I mentioned in my Linux.conf.au presentation a year and a half ago,
> > the main use
On Tue, Jul 10, 2007 at 04:31:44PM -0700, Andrew Morton wrote:
> On Sun, 01 Jul 2007 03:37:53 -0400
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > Add a "noversion" mount option to disable inode version updates.
>
> Why is this option being offered to our users? To reduce disk traffic,
> like n
On Sun, Jul 22, 2007 at 07:10:31AM +0300, Al Boldi wrote:
> Sounds great, but it may be advisable to hook this into the partition
> modification routines instead of mkfs/fsck. Which would mean that the
> partition manager could ask the kernel to instruct its fs subsystem to
> update the backup
On Mon, Jul 23, 2007 at 10:15:21AM +0200, Rene Herman wrote:
> On an integrated system like this, do you consider it acceptable to only do
> the MS-DOS partitions and not the other types that may be present _inside_
> those partitions? (MINIX subpartitions, BSD slices, ...). I believe those
> sh
On Sun, Jul 29, 2007 at 08:24:37PM +0100, Christoph Hellwig wrote:
> I'm a big proponent of having proper common delalloc code, but the
> one proposed here is not generic for the existing filesystem using
> delalloc. It's still on my todo list to revamp the xfs code to get
> rid of some of the exi
On Mon, Jul 30, 2007 at 09:39:39PM +0200, Miklos Szeredi wrote:
> > Extrapolating these %cpu number makes ZFS the fastest.
> >
> > Are you sure these numbers are correct?
>
> Note, that %cpu numbers for fuse filesystems are inherently skewed,
> because the CPU usage of the filesystem process itse
On Mon, Jul 30, 2007 at 06:13:35PM +0200, Jan Blunck wrote:
> Introduce white-out support to ext2.
>
> Known Bugs:
> - Needs a reserved inode number for white-outs
You picked different reserved inodes for the ext2 and ext3
filesystems. That's good for a NACK right there. The codepoints
(i.e., r
On Tue, Jul 31, 2007 at 09:44:36AM +0200, Jan Blunck wrote:
> Ok, this is pretty similar to the way I implemented this for tmpfs. The
> problem is that the union mount code is explicitly checking if the filesystem
> is supporting whiteout. I used to use a new filesystem flag (FS_WHITEOUT) for
> thi
On Wed, Sep 26, 2007 at 06:29:19PM -0500, Sachin Gaikwad wrote:
> Is it not the case that VFS takes care of all filesystems available ?
> VFS will see if a particular file belongs to ext3 or ext4 and call
> that FS's drivers to access information ??
No, it doesn't quite work that way. You have to
On Thu, Sep 27, 2007 at 04:19:12PM +0100, Alan Cox wrote:
> > Well it's not my call, just seems like a really bad idea to change the
> > error value. You can't claim full coverage for such testing anyway, it's
> > one of those things that people will complain about two releases later
> > saying it
On Thu, Sep 27, 2007 at 10:59:17AM -0700, Greg KH wrote:
> Come on now, I'm _very_ tired of this kind of discussion. Please go
> read the documentation on how to _use_ sysfs from userspace in such a
> way that you can properly access these data structures so that no
> breakage occurs.
I've read i
On Thu, Sep 27, 2007 at 02:34:45PM -0700, Greg KH wrote:
> Ok, how then should I advertise this better? What can we do better to
> help userspace programmers out in this regard?
Would you accept a patch which causes the deprecated sysfs
files/directories to disappear, even if CONFIG_SYS_DEPRECATE
On Thu, Sep 27, 2007 at 05:28:57PM -0600, Matthew Wilcox wrote:
> On Thu, Sep 27, 2007 at 07:19:27PM -0400, Theodore Tso wrote:
> > Would you accept a patch which causes the deprecated sysfs
> > files/directories to disappear, even if CONFIG_SYS_DEPRECATED is
> > defined, via
On Fri, Sep 28, 2007 at 02:31:46PM +0100, Christoph Hellwig wrote:
> On Fri, Sep 28, 2007 at 03:11:00PM +0200, Erik Mouw wrote:
> > There are however ways to confuse it: if you reformat an ext3
> > filesystem to reiserfs (version 3), mounting that filesystem without
> > "-t reiserfs" will trick mou
On Thu, Oct 04, 2007 at 04:57:08PM +0100, David Howells wrote:
> Stop the EXT2 filesystem from using iget() and read_inode(). Replace
> ext2_read_inode() with ext2_iget(), and call that instead of iget().
> ext2_iget() then uses iget_locked() directly and returns a proper error code
> instead of a
On Fri, Oct 19, 2007 at 10:49:03AM +0900, Tetsuo Handa wrote:
> /data/VMware: 349/19546112 files (32.1% non-contiguous), 31019203/39072080
> blocks
>
> Does non-contiguous mean fragmented?
> If so, where is ext3defrag?
Not necessarily; it just means that 32% of your files have at least
one disc
On Sat, Oct 20, 2007 at 12:39:33PM +0900, Tetsuo Handa wrote:
> Theodore Tso wrote:
> > beginning of every single block group. You have a small number of
> > files on your system (349) occupying an average of 348 megabytes. So
> > it's not at all surprising that the c
On Mon, Oct 22, 2007 at 08:58:11PM +0900, Tetsuo Handa wrote:
>
> --- Start VM ---
> --- Suspend VM ---
> [EMAIL PROTECTED] Ubuntu7.10]# filefrag Ubuntu7.10.vmem
> Ubuntu7.10.vmem: 751 extents found, perfection would be 5 extents
> [EMAIL PROTECTED] Ubuntu7.10]# sync
> [EMAIL PROTECTED] Ubuntu7.10
On Tue, Oct 23, 2007 at 07:38:20PM +0900, Tetsuo Handa wrote:
> > Are you sure the file isn't getting written by some background tasks
> > that you weren't aware of? This seems very strange; what
> > virtualization software are you using? VMware, Xen, KVM?
> I'm using VMware Workstation 6.0.0 bui
On Tue, Oct 30, 2007 at 04:26:04PM +0100, Jan Kara wrote:
> > This is a first try to move readdir() to become an inode operation. This is
> > necessary for a VFS implementation of "something like union-mounts" where a
> > readdir() needs to read the directory contents of multiple directories.
> > B
On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote:
>
> Ok, but let's look at this a bit more opportunistic / optimistic.
>
> Even after a black-out shutdown, the corruption is pretty minimal, using
> ext3fs at least.
>
After a unclean shutdown, assuming you have decent hardware that
does
On Tue, Jan 22, 2008 at 12:00:50AM -0700, Andreas Dilger wrote:
> > AIX had SIGDANGER some 15 years ago. Admittedly, that was sent when
> > the system was about to hit OOM, not when it was about to start swapping.
>
> I'd tried to advocate SIGDANGER some years ago as well, but none of
> the kerne
On Thu, May 17, 2001 at 03:00:28PM -0400, Jeff Garzik wrote:
> AFAIK the original stated intention of ext3 was
>
> cd linux/fs
> cp -a ext2 ext3
> # hack on ext3
>
> That leaves ext2 in ultra-stability,
> no-patches-unless-absolutely-necessary mode.
>
> IMHO prove a new featur
On Tue, Dec 05, 2006 at 01:50:17PM -0800, Andrew Morton wrote:
> This
>
> /*
>* Lorem ipsum dolor sit amet, consectetur
>* adipisicing elit, sed do eiusmod tempor
>* incididunt ut labore et dolore magna aliqua.
>*/
>
> is probably the most common, and is what
On Thu, Jan 04, 2007 at 12:34:16PM +0100, Jens Nie wrote:
>
> I think i found a bug in the ext3 filesystem. It deals with
> dereferencing symlinks. I have installed a fresh openSUSE 10.2 on an
> ext3 filesystem.
> After that i wanted to include some selfmade LaTeX-classes by creating
> a symlink
On Mon, Feb 05, 2007 at 09:40:08PM +0100, Jan Engelhardt wrote:
>
> On Feb 5 2007 18:32, Christoph Hellwig wrote:
> >
> >in two recent discussions (file_list_lock scalability and remount r/o
> >on suspend) I stumbled over this emergency remount feature. It's not
> >actually useful because it trie
On Thu, Feb 08, 2007 at 02:46:19PM -0800, hlily wrote:
>
> Suppose I have a list of data blocks, does Ext3 provide some functions that
> can help me to build a block list into an inode?
>
> If no such functions, could someone direct me to the right place in Ext3
> code that add block numbers to a
On Thu, Feb 08, 2007 at 11:47:39AM +0100, Jan Kara wrote:
> >
> > Well. Do we really? Are we looking for a 100% solution here, or a 90% one?
> Umm, I think that for ext3 having data on one end of the disk and
> indirect blocks on the other end of the disk does not quite help (not
> mentioning
On Wed, Feb 14, 2007 at 11:54:54AM -0800, Valerie Henson wrote:
> Background: The eXplode file system checker found a bug in ext2 fsync
> behavior. Do the following: truncate file A, create file B which
> reallocates one of A's old indirect blocks, fsync file B. If you then
> crash before file A'
On Thu, Feb 15, 2007 at 10:39:02AM -0600, Dave Kleikamp wrote:
> > It was my understanding from the persentation of Dawson that ext3 and jfs
> > have ame problem.
>
> Hmm. If jfs has the problem, it is a bug. jfs is designed to handle
> this correctly. I'm pretty sure I've fixed at least one
On Thu, Feb 15, 2007 at 11:28:46AM -0800, Junfeng Yang wrote:
>
> Actually, we found a crash-during-recovery bug in ext3 too. It's a race
> between resetting the journal super block and replay of the journal. This
> bug was fixed by Ted long time ago (3 years?).
That was found in your original
On Fri, Feb 23, 2007 at 05:37:23PM -0700, Andreas Dilger wrote:
> > Probably the only sane thing to do is to remember the bad sectors and
> > avoid attempting reading them; that would mean marking "automatic"
> > versus "explicitly requested" requests to determine whether or not to
> > filter th
On Mon, Feb 26, 2007 at 04:33:37PM +1100, Neil Brown wrote:
> Do we want a path in the other direction to handle write errors? The
> file system could say "Don't worry to much if this block cannot be
> written, just return an error and I will write it somewhere else"?
> This might allow md not to
On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote:
> In practice, there is a small number of programs that are both the
> common memory hogs and should be able to reduce their memory consumption
> by 10% or 20% without big problems when requested (e.g. Java VMs,
> Firefox and databases co
On Fri, Jan 25, 2008 at 10:34:25AM -0600, Eric Sandeen wrote:
> > But it was this concern which is why ext3 never exported freeze
> > functionality to userspace, even though other commercial filesystems
> > do support this. It wasn't that it wasn't considered, but the concern
> > about whether or
On Fri, Jan 25, 2008 at 03:18:51PM +0300, Dmitri Monakhov wrote:
> First of all Linux already have at least one open-source(dm-snap),
> and several commercial snapshot solutions.
Yes, but it requires that the filesystem be stored under LVM. Unlike
what EVMS v1 allowed us to do, we can't currentl
On Fri, Jan 25, 2008 at 05:55:51PM -0800, Bryan Henderson wrote:
> I was surprised to see AIX do late allocation by default, because IBM's
> traditional style is bulletproof systems. A system where a process can be
> killed at unpredictable times because of resource demands of unrelated
> proce
On Mon, Jan 28, 2008 at 07:30:05PM +, Pavel Machek wrote:
>
> As user pages are always in highmem, this should be easy to decide:
> only send SIGDANGER when highmem is full. (Yes, there are
> inodes/dentries/file descriptors in lowmem, but I doubt apps will
> respond to SIGDANGER by closing fi
On Sun, Feb 10, 2008 at 07:52:22AM +0100, Christoph Hellwig wrote:
> On Sat, Feb 09, 2008 at 10:39:33AM +0100, Christoph Hellwig wrote:
> > Move ext4 headers out of include/linux. This is just the trivial move,
> > there's some more thing that could be done later.
> >
> > Ted, is anything of thes
On Tue, Feb 12, 2008 at 03:28:26PM -0800, David Miller wrote:
> From: Jan Engelhardt <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 15:00:20 +0100 (CET)
>
> > Something looks wrong here. Why would btrfs need to zero at all?
>
> So that existing superblocks on the partition won't
> be interpreted as
On Mon, Feb 18, 2008 at 03:03:44PM +0100, Andi Kleen wrote:
> Tomasz Chmielewski <[EMAIL PROTECTED]> writes:
> >
> > Is it normal to expect the write speed go down to only few dozens of
> > kilobytes/s? Is it because of that many seeks? Can it be somehow
> > optimized?
>
> I have similar problems
On Mon, Feb 18, 2008 at 04:02:36PM +0100, Tomasz Chmielewski wrote:
> I tried to copy that filesystem once (when it was much smaller) with "rsync
> -a -H", but after 3 days, rsync was still building an index and didn't copy
> any file.
If you're going to copy the whole filesystem don't use rsync
On Mon, Feb 18, 2008 at 04:18:23PM +0100, Andi Kleen wrote:
> On Mon, Feb 18, 2008 at 09:16:41AM -0500, Theodore Tso wrote:
> > ext3 tries to keep inodes in the same block group as their containing
> > directory. If you have lots of hard links, obviously it can't really
>
On Mon, Feb 18, 2008 at 04:57:25PM +0100, Andi Kleen wrote:
> > Use cp
> > or a tar pipeline to move the files.
>
> Are you sure cp handles hardlinks correctly? I know tar does,
> but I have my doubts about cp.
I *think* GNU cp does the right thing with --preserve=links. I'm not
100% sure, thoug
On Mon, Feb 18, 2008 at 05:16:55PM +0100, Tomasz Chmielewski wrote:
> Theodore Tso schrieb:
>
>> I'd really need to know exactly what kind of operations you were
>> trying to do that were causing problems before I could say for sure.
>> Yes, you said you were removing
70 matches
Mail list logo
