Re: [PATCH 0/6] UDF cleanup and fixes
On Tue 22-05-07 15:39:31, Eric Sandeen wrote: > Eric Sandeen wrote: > > > Jan - > > > > I ran 2.6.21 + your udf patches from -mm through some udf tests which, > > oddly enough, can be found in the xfstests test suite in xfsprogs cvs > > from sgi. > > > > It looks much better than before, but I was able to trip some of your > > asserts. They were generated while fsx was running. The good news, > > though, is that fsx passed. :) I haven't looked into it much further > > yet, but wanted to let you know. > > Here's a short hacky testcase that trips the assert around line 123 of > udf/truncate.c I'm looking into it but you may immediately see what the > problem is...? Yes, yesterday I've also managed to create a simple testcase - sorry for not letting you know, I'd have saved you some time. I also know what the problem is: 1) discard_prealloc() shouldn't be called from udf_clear_inode() - at that point inode won't be written any more and thus changes to it won't be reflected. Actually, this bug is hidden by the fact that UDF calls discard_prealloc() on each filp release but anyway. 2) the second problem is extent rounding - when we discard prealloc we also truncate the extent to match i_size. That is fine but if the buffer remains in pagecache and is reused on second open, block_prepare_write() won't call udf_get_block() (as the buffer is already mapped) and thus the extent remains truncated even though we write after it's end. The easiest way out would be to simply leave the extent length rounded to block boundary but I have to check with the specification whether this is allowed... Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Tue 22-05-07 15:39:31, Eric Sandeen wrote: Eric Sandeen wrote: Jan - I ran 2.6.21 + your udf patches from -mm through some udf tests which, oddly enough, can be found in the xfstests test suite in xfsprogs cvs from sgi. It looks much better than before, but I was able to trip some of your asserts. They were generated while fsx was running. The good news, though, is that fsx passed. :) I haven't looked into it much further yet, but wanted to let you know. Here's a short hacky testcase that trips the assert around line 123 of udf/truncate.c I'm looking into it but you may immediately see what the problem is...? Yes, yesterday I've also managed to create a simple testcase - sorry for not letting you know, I'd have saved you some time. I also know what the problem is: 1) discard_prealloc() shouldn't be called from udf_clear_inode() - at that point inode won't be written any more and thus changes to it won't be reflected. Actually, this bug is hidden by the fact that UDF calls discard_prealloc() on each filp release but anyway. 2) the second problem is extent rounding - when we discard prealloc we also truncate the extent to match i_size. That is fine but if the buffer remains in pagecache and is reused on second open, block_prepare_write() won't call udf_get_block() (as the buffer is already mapped) and thus the extent remains truncated even though we write after it's end. The easiest way out would be to simply leave the extent length rounded to block boundary but I have to check with the specification whether this is allowed... Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
Eric Sandeen wrote:
> Jan -
>
> I ran 2.6.21 + your udf patches from -mm through some udf tests which,
> oddly enough, can be found in the xfstests test suite in xfsprogs cvs
> from sgi.
>
> It looks much better than before, but I was able to trip some of your
> asserts. They were generated while fsx was running. The good news,
> though, is that fsx passed. :) I haven't looked into it much further
> yet, but wanted to let you know.
Here's a short hacky testcase that trips the assert around line 123 of
udf/truncate.c I'm looking into it but you may immediately see what the
problem is...?
#include
#include
#include
#include
int main(int argc, char ** argv)
{
int fd;
char buf[65536];
fd = open("testfile", O_WRONLY|O_CREAT);
lseek(fd, 16797, SEEK_SET);
write(fd, buf, 22935);
close(fd);
fd = open("testfile", O_WRONLY);
lseek(fd, 31281, SEEK_SET);
write(fd, buf, 9592);
close(fd);
}
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
Eric Sandeen wrote:
Jan -
I ran 2.6.21 + your udf patches from -mm through some udf tests which,
oddly enough, can be found in the xfstests test suite in xfsprogs cvs
from sgi.
It looks much better than before, but I was able to trip some of your
asserts. They were generated while fsx was running. The good news,
though, is that fsx passed. :) I haven't looked into it much further
yet, but wanted to let you know.
Here's a short hacky testcase that trips the assert around line 123 of
udf/truncate.c I'm looking into it but you may immediately see what the
problem is...?
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
int main(int argc, char ** argv)
{
int fd;
char buf[65536];
fd = open(testfile, O_WRONLY|O_CREAT);
lseek(fd, 16797, SEEK_SET);
write(fd, buf, 22935);
close(fd);
fd = open(testfile, O_WRONLY);
lseek(fd, 31281, SEEK_SET);
write(fd, buf, 9592);
close(fd);
}
-Eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Fri 27-04-07 16:54:20, Eric Sandeen wrote: > Jan Kara wrote: > > Hello, > > > > the patches attached to six following emails implement some cleanup and > > fixes in the UDF code. The main two fixes are: > > 1) UDF now works correctly for files larger than 1GB. > > 2) Deleting a directory updates number of links to the parent directory > > correctly. > > See headers of following patches for details. > > > > The patches sustained some torturing so I hope that I did not introduce > > more bugs than I've fixed ;). Andrew, could you please put the patches > > into -mm kernels for testing? Thanks. > > > > Honza > > > > Jan - > > I ran 2.6.21 + your udf patches from -mm through some udf tests which, > oddly enough, can be found in the xfstests test suite in xfsprogs cvs > from sgi. > > It looks much better than before, but I was able to trip some of your > asserts. They were generated while fsx was running. The good news, > though, is that fsx passed. :) I haven't looked into it much further > yet, but wanted to let you know. Thanks for the news. I'll try running fsx to see if I'll be able to reproduce the problem (I think I was testing the patches with fsx but maybe it didn't run long enough). Honza > BUG: at /src/linux-2.6.21-rc5/fs/udf/truncate.c:123 udf_discard_prealloc() > [] udf_discard_prealloc+0x2d8/0x2ed [udf] > [] udf_release_file+0x15/0x1e [udf] > [] __fput+0xa5/0x15b > [] generic_file_open+0x0/0x45 > [] __dentry_open+0x115/0x17a > [] nameidata_to_filp+0x24/0x33 > [] do_filp_open+0x32/0x39 > [] get_unused_fd+0x50/0xb6 > [] do_sys_open+0x42/0xbe > [] sys_open+0x1c/0x1e > [] syscall_call+0x7/0xb > === > BUG: at /src/linux-2.6.21-rc5/fs/udf/truncate.c:123 udf_discard_prealloc() > [] udf_discard_prealloc+0x2d8/0x2ed [udf] > [] udf_clear_inode+0x1b/0x34 [udf] > [] clear_inode+0xb2/0x100 > [] truncate_inode_pages+0x17/0x1a > [] dispose_list+0x33/0xb1 > [] invalidate_inodes+0xa8/0xbd > [] generic_shutdown_super+0x31/0xb7 > [] kill_block_super+0x1d/0x2d > [] deactivate_super+0x52/0x65 > [] sys_umount+0x1f2/0x21a > [] audit_syscall_entry+0x10d/0x137 > [] sys_oldumount+0x17/0x1a > [] syscall_call+0x7/0xb -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Fri 27-04-07 16:54:20, Eric Sandeen wrote: Jan Kara wrote: Hello, the patches attached to six following emails implement some cleanup and fixes in the UDF code. The main two fixes are: 1) UDF now works correctly for files larger than 1GB. 2) Deleting a directory updates number of links to the parent directory correctly. See headers of following patches for details. The patches sustained some torturing so I hope that I did not introduce more bugs than I've fixed ;). Andrew, could you please put the patches into -mm kernels for testing? Thanks. Honza Jan - I ran 2.6.21 + your udf patches from -mm through some udf tests which, oddly enough, can be found in the xfstests test suite in xfsprogs cvs from sgi. It looks much better than before, but I was able to trip some of your asserts. They were generated while fsx was running. The good news, though, is that fsx passed. :) I haven't looked into it much further yet, but wanted to let you know. Thanks for the news. I'll try running fsx to see if I'll be able to reproduce the problem (I think I was testing the patches with fsx but maybe it didn't run long enough). Honza BUG: at /src/linux-2.6.21-rc5/fs/udf/truncate.c:123 udf_discard_prealloc() [de969274] udf_discard_prealloc+0x2d8/0x2ed [udf] [de95eea5] udf_release_file+0x15/0x1e [udf] [c046f5f0] __fput+0xa5/0x15b [c046d0d2] generic_file_open+0x0/0x45 [c046d3f3] __dentry_open+0x115/0x17a [c046d4d2] nameidata_to_filp+0x24/0x33 [c046d513] do_filp_open+0x32/0x39 [c046d278] get_unused_fd+0x50/0xb6 [c046d55c] do_sys_open+0x42/0xbe [c046d611] sys_open+0x1c/0x1e [c0404db8] syscall_call+0x7/0xb === BUG: at /src/linux-2.6.21-rc5/fs/udf/truncate.c:123 udf_discard_prealloc() [de969274] udf_discard_prealloc+0x2d8/0x2ed [udf] [de9632ae] udf_clear_inode+0x1b/0x34 [udf] [c047eb56] clear_inode+0xb2/0x100 [c0459a95] truncate_inode_pages+0x17/0x1a [c047edfe] dispose_list+0x33/0xb1 [c047f1f3] invalidate_inodes+0xa8/0xbd [c046fff2] generic_shutdown_super+0x31/0xb7 [c0470095] kill_block_super+0x1d/0x2d [c047013d] deactivate_super+0x52/0x65 [c0480de8] sys_umount+0x1f2/0x21a [c044e33f] audit_syscall_entry+0x10d/0x137 [c0480e27] sys_oldumount+0x17/0x1a [c0404db8] syscall_call+0x7/0xb -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
Jan Kara wrote: > Hello, > > the patches attached to six following emails implement some cleanup and > fixes in the UDF code. The main two fixes are: > 1) UDF now works correctly for files larger than 1GB. > 2) Deleting a directory updates number of links to the parent directory > correctly. > See headers of following patches for details. > > The patches sustained some torturing so I hope that I did not introduce > more bugs than I've fixed ;). Andrew, could you please put the patches > into -mm kernels for testing? Thanks. > > Honza > Jan - I ran 2.6.21 + your udf patches from -mm through some udf tests which, oddly enough, can be found in the xfstests test suite in xfsprogs cvs from sgi. It looks much better than before, but I was able to trip some of your asserts. They were generated while fsx was running. The good news, though, is that fsx passed. :) I haven't looked into it much further yet, but wanted to let you know. Thanks, -Eric BUG: at /src/linux-2.6.21-rc5/fs/udf/truncate.c:123 udf_discard_prealloc() [] udf_discard_prealloc+0x2d8/0x2ed [udf] [] udf_release_file+0x15/0x1e [udf] [] __fput+0xa5/0x15b [] generic_file_open+0x0/0x45 [] __dentry_open+0x115/0x17a [] nameidata_to_filp+0x24/0x33 [] do_filp_open+0x32/0x39 [] get_unused_fd+0x50/0xb6 [] do_sys_open+0x42/0xbe [] sys_open+0x1c/0x1e [] syscall_call+0x7/0xb === BUG: at /src/linux-2.6.21-rc5/fs/udf/truncate.c:123 udf_discard_prealloc() [] udf_discard_prealloc+0x2d8/0x2ed [udf] [] udf_clear_inode+0x1b/0x34 [udf] [] clear_inode+0xb2/0x100 [] truncate_inode_pages+0x17/0x1a [] dispose_list+0x33/0xb1 [] invalidate_inodes+0xa8/0xbd [] generic_shutdown_super+0x31/0xb7 [] kill_block_super+0x1d/0x2d [] deactivate_super+0x52/0x65 [] sys_umount+0x1f2/0x21a [] audit_syscall_entry+0x10d/0x137 [] sys_oldumount+0x17/0x1a [] syscall_call+0x7/0xb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
Jan Kara wrote: Hello, the patches attached to six following emails implement some cleanup and fixes in the UDF code. The main two fixes are: 1) UDF now works correctly for files larger than 1GB. 2) Deleting a directory updates number of links to the parent directory correctly. See headers of following patches for details. The patches sustained some torturing so I hope that I did not introduce more bugs than I've fixed ;). Andrew, could you please put the patches into -mm kernels for testing? Thanks. Honza Jan - I ran 2.6.21 + your udf patches from -mm through some udf tests which, oddly enough, can be found in the xfstests test suite in xfsprogs cvs from sgi. It looks much better than before, but I was able to trip some of your asserts. They were generated while fsx was running. The good news, though, is that fsx passed. :) I haven't looked into it much further yet, but wanted to let you know. Thanks, -Eric BUG: at /src/linux-2.6.21-rc5/fs/udf/truncate.c:123 udf_discard_prealloc() [de969274] udf_discard_prealloc+0x2d8/0x2ed [udf] [de95eea5] udf_release_file+0x15/0x1e [udf] [c046f5f0] __fput+0xa5/0x15b [c046d0d2] generic_file_open+0x0/0x45 [c046d3f3] __dentry_open+0x115/0x17a [c046d4d2] nameidata_to_filp+0x24/0x33 [c046d513] do_filp_open+0x32/0x39 [c046d278] get_unused_fd+0x50/0xb6 [c046d55c] do_sys_open+0x42/0xbe [c046d611] sys_open+0x1c/0x1e [c0404db8] syscall_call+0x7/0xb === BUG: at /src/linux-2.6.21-rc5/fs/udf/truncate.c:123 udf_discard_prealloc() [de969274] udf_discard_prealloc+0x2d8/0x2ed [udf] [de9632ae] udf_clear_inode+0x1b/0x34 [udf] [c047eb56] clear_inode+0xb2/0x100 [c0459a95] truncate_inode_pages+0x17/0x1a [c047edfe] dispose_list+0x33/0xb1 [c047f1f3] invalidate_inodes+0xa8/0xbd [c046fff2] generic_shutdown_super+0x31/0xb7 [c0470095] kill_block_super+0x1d/0x2d [c047013d] deactivate_super+0x52/0x65 [c0480de8] sys_umount+0x1f2/0x21a [c044e33f] audit_syscall_entry+0x10d/0x137 [c0480e27] sys_oldumount+0x17/0x1a [c0404db8] syscall_call+0x7/0xb - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
> On Thu, Apr 12, 2007 at 18:01:12 +0200, Jan Kara wrote: > > On Wed 04-04-07 08:36:20, Tino Keitel wrote: > > > On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote: > > > > > > [...] > > > > > > > Well, it works for me on 32-bit as well, right up to 100% full. > > > > No problems at all... > > > > > > Maybe it depends on the kernel. I patched 2.6.20 with the patches > > > above and got the described behaviour. > > I've sent you an email with a few questions but probably it got lost in > > the noise... Are you able to reproduce the problem? Have you reproduced the > > problem on a freshly created UDF image or was it some older image? > > Hi, > > I can't remember of any errors in the kernel or about not available > space. It was an image file that I expermimented with, and I did > multiple mkudffs runs on the file. Could it be that the behaviour was > caused by stale data inside the image? OK, thanks for info. Umm, I don't find it likely that some stale data in the image would cause this but maybe something could confuse mkudffs (like it was expecting zeros somewhere where they were not). If you had some recipe how to reproduce the problem (it would be enough if you had something like: I have this file, I run mkudffs, mount it, see wrong free blocks count), I can have a look at it. Otherwise, it's hard to track it down... Honza - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Thu, Apr 12, 2007 at 18:01:12 +0200, Jan Kara wrote: On Wed 04-04-07 08:36:20, Tino Keitel wrote: On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote: [...] Well, it works for me on 32-bit as well, right up to 100% full. No problems at all... Maybe it depends on the kernel. I patched 2.6.20 with the patches above and got the described behaviour. I've sent you an email with a few questions but probably it got lost in the noise... Are you able to reproduce the problem? Have you reproduced the problem on a freshly created UDF image or was it some older image? Hi, I can't remember of any errors in the kernel or about not available space. It was an image file that I expermimented with, and I did multiple mkudffs runs on the file. Could it be that the behaviour was caused by stale data inside the image? OK, thanks for info. Umm, I don't find it likely that some stale data in the image would cause this but maybe something could confuse mkudffs (like it was expecting zeros somewhere where they were not). If you had some recipe how to reproduce the problem (it would be enough if you had something like: I have this file, I run mkudffs, mount it, see wrong free blocks count), I can have a look at it. Otherwise, it's hard to track it down... Honza - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Thu, Apr 12, 2007 at 18:01:12 +0200, Jan Kara wrote: > On Wed 04-04-07 08:36:20, Tino Keitel wrote: > > On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote: > > > > [...] > > > > > Well, it works for me on 32-bit as well, right up to 100% full. > > > No problems at all... > > > > Maybe it depends on the kernel. I patched 2.6.20 with the patches > > above and got the described behaviour. > I've sent you an email with a few questions but probably it got lost in > the noise... Are you able to reproduce the problem? Have you reproduced the > problem on a freshly created UDF image or was it some older image? Hi, I can't remember of any errors in the kernel or about not available space. It was an image file that I expermimented with, and I did multiple mkudffs runs on the file. Could it be that the behaviour was caused by stale data inside the image? Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Wed 04-04-07 08:36:20, Tino Keitel wrote: > On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote: > > [...] > > > Well, it works for me on 32-bit as well, right up to 100% full. > > No problems at all... > > Maybe it depends on the kernel. I patched 2.6.20 with the patches > above and got the described behaviour. I've sent you an email with a few questions but probably it got lost in the noise... Are you able to reproduce the problem? Have you reproduced the problem on a freshly created UDF image or was it some older image? Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Wed 04-04-07 08:36:20, Tino Keitel wrote: On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote: [...] Well, it works for me on 32-bit as well, right up to 100% full. No problems at all... Maybe it depends on the kernel. I patched 2.6.20 with the patches above and got the described behaviour. I've sent you an email with a few questions but probably it got lost in the noise... Are you able to reproduce the problem? Have you reproduced the problem on a freshly created UDF image or was it some older image? Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Thu, Apr 12, 2007 at 18:01:12 +0200, Jan Kara wrote: On Wed 04-04-07 08:36:20, Tino Keitel wrote: On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote: [...] Well, it works for me on 32-bit as well, right up to 100% full. No problems at all... Maybe it depends on the kernel. I patched 2.6.20 with the patches above and got the described behaviour. I've sent you an email with a few questions but probably it got lost in the noise... Are you able to reproduce the problem? Have you reproduced the problem on a freshly created UDF image or was it some older image? Hi, I can't remember of any errors in the kernel or about not available space. It was an image file that I expermimented with, and I did multiple mkudffs runs on the file. Could it be that the behaviour was caused by stale data inside the image? Regards, Tino - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote: [...] > Well, it works for me on 32-bit as well, right up to 100% full. > No problems at all... Maybe it depends on the kernel. I patched 2.6.20 with the patches above and got the described behaviour. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote: [...] Well, it works for me on 32-bit as well, right up to 100% full. No problems at all... Maybe it depends on the kernel. I patched 2.6.20 with the patches above and got the described behaviour. Regards, Tino - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
Tino Keitel wrote: > On Fri, Mar 30, 2007 at 14:06:34 -0400, Chuck Ebbert wrote: >> Tino Keitel wrote: >>> On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: Hello, the patches attached to six following emails implement some cleanup and fixes in the UDF code. The main two fixes are: 1) UDF now works correctly for files larger than 1GB. >>> Hi, >>> >>> I tried 2.6.20 with your patches and got the following behaviour: >>> >>> $ ls -la dvd.udf >>> -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf >>> $ mount -o loop -t udf dvd.udf /media/udf/ >>> $ df /media/udf/ >>> Filesystem 1K-blocks Used Available Use% Mounted on >>> /home/storage/dvd.udf >>>4588506 -8584746354 8589334860 - /media/udf >>>^^ >>> $ ls -la /media/udf/ >>> total 4587521 >>> drwxr-xr-x 3 root root144 Mar 29 15:36 . >>> drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. >>> -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar >>> drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found >>> >> Is that on a 32-bit machine? > > Yes, it's an Intel Core Duo. Well, it works for me on 32-bit as well, right up to 100% full. No problems at all... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Fri 30-03-07 06:59:23, Tino Keitel wrote: > On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: > > Hello, > > > > the patches attached to six following emails implement some cleanup and > > fixes in the UDF code. The main two fixes are: > > 1) UDF now works correctly for files larger than 1GB. > > Hi, > > I tried 2.6.20 with your patches and got the following behaviour: > > $ ls -la dvd.udf > -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf > $ mount -o loop -t udf dvd.udf /media/udf/ > $ df /media/udf/ > Filesystem 1K-blocks Used Available Use% Mounted on > /home/storage/dvd.udf >4588506 -8584746354 8589334860 - /media/udf >^^ > $ ls -la /media/udf/ > total 4587521 > drwxr-xr-x 3 root root144 Mar 29 15:36 . > drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. > -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar > drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found Looking more into this it looks like a bug in accounting of free blocks than some overflow. Was dvd.udf a freshly created image by mkudffs? Are there any errors in the log or did fs report anything like ENOSPC? Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Fri 30-03-07 06:59:23, Tino Keitel wrote: > On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: > > Hello, > > > > the patches attached to six following emails implement some cleanup and > > fixes in the UDF code. The main two fixes are: > > 1) UDF now works correctly for files larger than 1GB. > > Hi, > > I tried 2.6.20 with your patches and got the following behaviour: > > $ ls -la dvd.udf > -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf > $ mount -o loop -t udf dvd.udf /media/udf/ > $ df /media/udf/ > Filesystem 1K-blocks Used Available Use% Mounted on > /home/storage/dvd.udf >4588506 -8584746354 8589334860 - /media/udf >^^ > $ ls -la /media/udf/ > total 4587521 > drwxr-xr-x 3 root root144 Mar 29 15:36 . > drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. > -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar > drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found Thanks for report. I'll have a look at it. I've tested my patches on a 64-bit machine and obviously some computation overflows on a 32-bit one... Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Fri 30-03-07 06:59:23, Tino Keitel wrote: On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: Hello, the patches attached to six following emails implement some cleanup and fixes in the UDF code. The main two fixes are: 1) UDF now works correctly for files larger than 1GB. Hi, I tried 2.6.20 with your patches and got the following behaviour: $ ls -la dvd.udf -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf $ mount -o loop -t udf dvd.udf /media/udf/ $ df /media/udf/ Filesystem 1K-blocks Used Available Use% Mounted on /home/storage/dvd.udf 4588506 -8584746354 8589334860 - /media/udf ^^ $ ls -la /media/udf/ total 4587521 drwxr-xr-x 3 root root144 Mar 29 15:36 . drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found Thanks for report. I'll have a look at it. I've tested my patches on a 64-bit machine and obviously some computation overflows on a 32-bit one... Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Fri 30-03-07 06:59:23, Tino Keitel wrote: On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: Hello, the patches attached to six following emails implement some cleanup and fixes in the UDF code. The main two fixes are: 1) UDF now works correctly for files larger than 1GB. Hi, I tried 2.6.20 with your patches and got the following behaviour: $ ls -la dvd.udf -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf $ mount -o loop -t udf dvd.udf /media/udf/ $ df /media/udf/ Filesystem 1K-blocks Used Available Use% Mounted on /home/storage/dvd.udf 4588506 -8584746354 8589334860 - /media/udf ^^ $ ls -la /media/udf/ total 4587521 drwxr-xr-x 3 root root144 Mar 29 15:36 . drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found Looking more into this it looks like a bug in accounting of free blocks than some overflow. Was dvd.udf a freshly created image by mkudffs? Are there any errors in the log or did fs report anything like ENOSPC? Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
Tino Keitel wrote: On Fri, Mar 30, 2007 at 14:06:34 -0400, Chuck Ebbert wrote: Tino Keitel wrote: On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: Hello, the patches attached to six following emails implement some cleanup and fixes in the UDF code. The main two fixes are: 1) UDF now works correctly for files larger than 1GB. Hi, I tried 2.6.20 with your patches and got the following behaviour: $ ls -la dvd.udf -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf $ mount -o loop -t udf dvd.udf /media/udf/ $ df /media/udf/ Filesystem 1K-blocks Used Available Use% Mounted on /home/storage/dvd.udf 4588506 -8584746354 8589334860 - /media/udf ^^ $ ls -la /media/udf/ total 4587521 drwxr-xr-x 3 root root144 Mar 29 15:36 . drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found Is that on a 32-bit machine? Yes, it's an Intel Core Duo. Well, it works for me on 32-bit as well, right up to 100% full. No problems at all... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Fri, Mar 30, 2007 at 14:06:34 -0400, Chuck Ebbert wrote: > Tino Keitel wrote: > > On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: > >> Hello, > >> > >> the patches attached to six following emails implement some cleanup and > >> fixes in the UDF code. The main two fixes are: > >> 1) UDF now works correctly for files larger than 1GB. > > > > Hi, > > > > I tried 2.6.20 with your patches and got the following behaviour: > > > > $ ls -la dvd.udf > > -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf > > $ mount -o loop -t udf dvd.udf /media/udf/ > > $ df /media/udf/ > > Filesystem 1K-blocks Used Available Use% Mounted on > > /home/storage/dvd.udf > >4588506 -8584746354 8589334860 - /media/udf > >^^ > > $ ls -la /media/udf/ > > total 4587521 > > drwxr-xr-x 3 root root144 Mar 29 15:36 . > > drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. > > -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar > > drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found > > > > Is that on a 32-bit machine? Yes, it's an Intel Core Duo. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Fri, Mar 30, 2007 at 14:06:34 -0400, Chuck Ebbert wrote: Tino Keitel wrote: On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: Hello, the patches attached to six following emails implement some cleanup and fixes in the UDF code. The main two fixes are: 1) UDF now works correctly for files larger than 1GB. Hi, I tried 2.6.20 with your patches and got the following behaviour: $ ls -la dvd.udf -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf $ mount -o loop -t udf dvd.udf /media/udf/ $ df /media/udf/ Filesystem 1K-blocks Used Available Use% Mounted on /home/storage/dvd.udf 4588506 -8584746354 8589334860 - /media/udf ^^ $ ls -la /media/udf/ total 4587521 drwxr-xr-x 3 root root144 Mar 29 15:36 . drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found Is that on a 32-bit machine? Yes, it's an Intel Core Duo. Regards, Tino - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
Tino Keitel wrote: > On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: >> Hello, >> >> the patches attached to six following emails implement some cleanup and >> fixes in the UDF code. The main two fixes are: >> 1) UDF now works correctly for files larger than 1GB. > > Hi, > > I tried 2.6.20 with your patches and got the following behaviour: > > $ ls -la dvd.udf > -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf > $ mount -o loop -t udf dvd.udf /media/udf/ > $ df /media/udf/ > Filesystem 1K-blocks Used Available Use% Mounted on > /home/storage/dvd.udf >4588506 -8584746354 8589334860 - /media/udf >^^ > $ ls -la /media/udf/ > total 4587521 > drwxr-xr-x 3 root root144 Mar 29 15:36 . > drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. > -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar > drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found > Is that on a 32-bit machine? Seems to work okay on a 64-bit system here: $ df /mnt/udf Filesystem 1K-blocks Used Available Use% Mounted on /var/tmp/udf_fs4798938 302 4798636 1% /mnt/udf $ ll /var/tmp/udf_fs -rw-r--r-- 1 root root 491520 Mar 30 13:49 /var/tmp/udf_fs And after creating a large file in the filesystem: $ ll /mnt/udf/udf_file -rw-r--r-- 1 root root 475136 Mar 30 14:01 /mnt/udf/udf_file $ df /mnt/udf Filesystem 1K-blocks Used Available Use% Mounted on /var/tmp/udf_fs4798938 4640304158634 97% /mnt/udf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
Tino Keitel wrote: On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: Hello, the patches attached to six following emails implement some cleanup and fixes in the UDF code. The main two fixes are: 1) UDF now works correctly for files larger than 1GB. Hi, I tried 2.6.20 with your patches and got the following behaviour: $ ls -la dvd.udf -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf $ mount -o loop -t udf dvd.udf /media/udf/ $ df /media/udf/ Filesystem 1K-blocks Used Available Use% Mounted on /home/storage/dvd.udf 4588506 -8584746354 8589334860 - /media/udf ^^ $ ls -la /media/udf/ total 4587521 drwxr-xr-x 3 root root144 Mar 29 15:36 . drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found Is that on a 32-bit machine? Seems to work okay on a 64-bit system here: $ df /mnt/udf Filesystem 1K-blocks Used Available Use% Mounted on /var/tmp/udf_fs4798938 302 4798636 1% /mnt/udf $ ll /var/tmp/udf_fs -rw-r--r-- 1 root root 491520 Mar 30 13:49 /var/tmp/udf_fs And after creating a large file in the filesystem: $ ll /mnt/udf/udf_file -rw-r--r-- 1 root root 475136 Mar 30 14:01 /mnt/udf/udf_file $ df /mnt/udf Filesystem 1K-blocks Used Available Use% Mounted on /var/tmp/udf_fs4798938 4640304158634 97% /mnt/udf - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: > Hello, > > the patches attached to six following emails implement some cleanup and > fixes in the UDF code. The main two fixes are: > 1) UDF now works correctly for files larger than 1GB. Hi, I tried 2.6.20 with your patches and got the following behaviour: $ ls -la dvd.udf -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf $ mount -o loop -t udf dvd.udf /media/udf/ $ df /media/udf/ Filesystem 1K-blocks Used Available Use% Mounted on /home/storage/dvd.udf 4588506 -8584746354 8589334860 - /media/udf ^^ $ ls -la /media/udf/ total 4587521 drwxr-xr-x 3 root root144 Mar 29 15:36 . drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: Hello, the patches attached to six following emails implement some cleanup and fixes in the UDF code. The main two fixes are: 1) UDF now works correctly for files larger than 1GB. Hi, I tried 2.6.20 with your patches and got the following behaviour: $ ls -la dvd.udf -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf $ mount -o loop -t udf dvd.udf /media/udf/ $ df /media/udf/ Filesystem 1K-blocks Used Available Use% Mounted on /home/storage/dvd.udf 4588506 -8584746354 8589334860 - /media/udf ^^ $ ls -la /media/udf/ total 4587521 drwxr-xr-x 3 root root144 Mar 29 15:36 . drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found Regards, Tino - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] UDF cleanup and fixes
Hello, the patches attached to six following emails implement some cleanup and fixes in the UDF code. The main two fixes are: 1) UDF now works correctly for files larger than 1GB. 2) Deleting a directory updates number of links to the parent directory correctly. See headers of following patches for details. The patches sustained some torturing so I hope that I did not introduce more bugs than I've fixed ;). Andrew, could you please put the patches into -mm kernels for testing? Thanks. Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] UDF cleanup and fixes
Hello, the patches attached to six following emails implement some cleanup and fixes in the UDF code. The main two fixes are: 1) UDF now works correctly for files larger than 1GB. 2) Deleting a directory updates number of links to the parent directory correctly. See headers of following patches for details. The patches sustained some torturing so I hope that I did not introduce more bugs than I've fixed ;). Andrew, could you please put the patches into -mm kernels for testing? Thanks. Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
