On Mon, 2010-11-22 at 17:21 +0800, Li Zefan wrote:
Have a look in fs/super.c:generic_shutdown_super(), called by
fs/super.c:kill_anon_super(), where the super method -put_super() is
called, setting the super s_fs_info to NULL, before taking the sb_lock
and removing it from the list of
On Fri 19-11-10 16:16:19, Nick Piggin wrote:
On Fri, Nov 19, 2010 at 01:45:52AM +0100, Jan Kara wrote:
On Wed 17-11-10 22:28:34, Andrew Morton wrote:
The fact that a call to -write_begin can randomly return with s_umount
held, to be randomly released at some random time in the future is a
There is a typo in __btrfs_prealloc_file_range() where we set the i_size to
actual_len/cur_offset, and then just set it to cur_offset again, and do the same
with btrfs_ordered_update_i_size(). This fixes it back to keeping i_size in a
local variable and then updating i_size properly. Tested this
We have been failing xfstest 228 forever, because we don't check to make sure
the new inode size is acceptable as far as RLIMIT is concerned. Just check to
make sure it's ok to create a inode with this new size and error out if not.
With this patch we now pass 228. Thanks,
Signed-off-by: Josef
On Fri, 19 Nov 2010, Li Zefan wrote:
We've done the check for src_offset and src_length, and We should
also check dest_offset, otherwise we'll corrupt the destination
file:
(After cloning file1 to file2 with unaligned dest_offset)
# cat /mnt/file2
cat: /mnt/file2: Input/output error
On Fri, 19 Nov 2010, Li Zefan wrote:
Set src_offset = 0, src_length = 20K, dest_offset = 20K. And the
original filesize of the dest file 'file2' is 30K:
# ls -l /mnt/file2
-rw-r--r-- 1 root root 30720 Nov 18 16:42 /mnt/file2
Now clone file1 to file2, the dest file should be 40K, but
I thought I would try btrfs on a new installation of f14. yes, I know
its experimental but stable so it seemed to be a good time to try it.
I am not sure if I have missed something out of all my searching but am
I correct in thinking that currently:
I. it is not possible to boot from a
Hi,
On Tue, Nov 23, 2010 at 10:19:43AM +1100, david grant wrote:
I thought I would try btrfs on a new installation of f14. yes, I know
its experimental but stable so it seemed to be a good time to try it.
I am not sure if I have missed something out of all my searching but am
I correct in
On Fri, Nov 19, 2010 at 12:09 PM, Brian Sullivan bexam...@gmail.com wrote:
On Fri, Nov 19, 2010 at 6:46 AM, Josef Bacik jo...@redhat.com wrote:
On Fri, Nov 19, 2010 at 09:32:46AM -0500, Chris Mason wrote:
I just wanted to confirm, you're seeing this with 2.6.37-rc? I thought
I had fixed up
On Wed, 17 Nov 2010 21:18:13 -0600
Eric Sandeen sand...@redhat.com wrote:
On 11/17/10 12:10 AM, Nick Piggin wrote:
On Tue, Nov 16, 2010 at 11:05:52PM -0600, Eric Sandeen wrote:
On 11/16/10 10:38 PM, Nick Piggin wrote:
as for the locking problems ... sorry about that!
That's no problem.
Excerpts from Brian Sullivan's message of 2010-11-22 18:29:42 -0500:
On Fri, Nov 19, 2010 at 12:09 PM, Brian Sullivan bexam...@gmail.com wrote:
On Fri, Nov 19, 2010 at 6:46 AM, Josef Bacik jo...@redhat.com wrote:
On Fri, Nov 19, 2010 at 09:32:46AM -0500, Chris Mason wrote:
I just wanted
2010/11/23, david grant d...@david-grant.com:
I thought I would try btrfs on a new installation of f14. yes, I know
its experimental but stable so it seemed to be a good time to try it.
I am not sure if I have missed something out of all my searching but am
I correct in thinking that
On Mon, Nov 22, 2010 at 10:47 PM, Wenyi Liu qingshen...@gmail.com wrote:
2010/11/23, david grant d...@david-grant.com:
I thought I would try btrfs on a new installation of f14. yes, I know
its experimental but stable so it seemed to be a good time to try it.
I am not sure if I have missed
13 matches
Mail list logo
