On Mon, 15 Aug 2011 00:54:18 -0500
C Anthony Risinger wrote:
> but meh, who really knows anyway; it certainly would be incredibly
> cool to have a common denominator greater than FAT, especially since
> commodity flash chips are 8-16GB now.
Consider using UDF: http://homepage.mac.com/wenguangwan
Added extended test cases for btrfs snapshot. This adds a new
user-variable SCRATCH_DEV_POOL which should be set to a disk set.
Signed-off-by: Anand Jain
---
257 | 192
+
257.out |2 +
common.rc | 86 ++
Hi Yolanda,
are you using compression? If not and you were also using something like
LaTeX for yout thesis you could use grep to locate it on e.g. /dev/sda
then copy it out there and at least have you thesis work saved.
I did something like that once and it worked nicely
Lg Niklas
On Mon, 2011-
There are patches elsewhere in the mailing list to allow one to mount
a broken-due-to-transid-mismatch filesystem readonly, which should
work in this case.
Regarding your backup regimen, consider using rsync instead of dd:
after the initial backup, rsync can update the existing backup _much_
more
> Regarding your backup regimen, consider using rsync instead of dd:
> after the initial backup, rsync can update the existing backup _much_
> more quickly, making it practical to do a backup every night, or even
> multiple times a day. dd also has the downside of potentially
> _really_ confusing
Hi all -
btrfs_permission currently returns -EROFS when the root is set read-only
and the open is requested read-write. It doesn't make an exception for
device files. Is this intentional?
-Jeff
--
Jeff Mahoney
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs
2011/8/3 Chris Mason :
> Excerpts from Erik Jensen's message of 2011-08-03 02:57:24 -0400:
>> The lack of any information on when btrfsck might be ready is a real
>> headache to those deciding what to do with a corrupted file system.
>>
>> I am currently sitting on a btrfs array of 10 disks that ha
Excerpts from Jeff Mahoney's message of 2011-08-15 09:11:24 -0400:
> Hi all -
>
> btrfs_permission currently returns -EROFS when the root is set read-only
> and the open is requested read-write. It doesn't make an exception for
> device files. Is this intentional?
No, definitely not intentional
Excerpts from ivo welch's message of 2011-08-14 20:34:14 -0400:
> curiosity question---could btrfs be licensed in multiple ways to allow
> Apple and other vendors to adopt it? as end users, having one good
> file system that works everywhere as a main root system would be
> heaven...
One of the w
Excerpts from krz...@gmail.com's message of 2011-08-13 17:59:34 -0400:
> I wonder if it would be possible to implement instant unlinking
> directory with files in it. Since btrfs is based on b trees it could
> be possible. Filesystem would have to "loose" all information on
> directory and object i
On 08/15/2011 10:58 AM, Chris Mason wrote:
Excerpts from Jeff Mahoney's message of 2011-08-15 09:11:24 -0400:
Hi all -
btrfs_permission currently returns -EROFS when the root is set read-only
and the open is requested read-write. It doesn't make an exception for
device files. Is this intentiona
This patch tightens the read-only access checks in btrfs_permission to
match the constraints in inode_permission. Currently, even though the
device node itself will be unmodified, read-write access to device nodes
is denied to when the device node resides on a read-only subvolume or a
is a fil
Maybe Apple and Microsoft can write a GPL FUSE-like wrapper for btrfs.
On Mon, Aug 15, 2011 at 10:15, Chris Mason wrote:
> Excerpts from ivo welch's message of 2011-08-14 20:34:14 -0400:
>> curiosity question---could btrfs be licensed in multiple ways to allow
>> Apple and other vendors to adopt
Hi all -
The following 9 patches add more error handling to the btrfs code:
- Add btrfs_panic
- Catch locking failures in {set,clear}_extent_bit
- Push up set_extent_bit errors to callers
- Push up lock_extent errors to callers
- Push up clear_extent_bit errors to callers
- Push up unlock_e
As part of the effort to eliminate BUG_ON as an error handling
technique, we need to determine which errors are actual logic errors,
which are on-disk corruption, and which are normal runtime errors
e.g. -ENOMEM.
Annotating these error cases is helpful to understand and report them.
This pa
The *_state functions can only return 0 or -EEXIST. This patch addresses
the cases where those functions return -EEXIST, representing a locking
failure. It handles them by panicking with an appropriate error message.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/extent_io.c | 36
The previous patch pushed the clear_extent_bit error handling up a level,
which included unlock_extent and unlock_extent_cache.
This patch pushes the BUG_ON up into the callers of those functions.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/compression.c |9 ++--
fs/btrfs/disk-io.c
btrfs_pin_extent looks up a block group and then calls pin_down_extent
with it. If the lookup fails, it should return -ENOENT to allow callers
to handle the error condition. For the three existing callers, it is
a logic error if the lookup fails and a panic will occur.
Signed-off-by: Jeff Maho
In the locking case, set_extent_bit can return -EEXIST but callers
already handle that.
In the non-locking case, it can't fail. Memory allocation failures are
handled by BUG_ON.
This patch pushes up the BUG_ONs from set_extent_bit to callers, except
where -ENOMEM can't occur (e.g. __GFP_WAI
This patch handles btrfs_start_transaction failures that don't occur
in a loop and are obvious to simply push up. In all cases except the
mark_garbage_root case, the error is already handled by BUG_ON in the
caller.
Update v2: This version also checks the returns from btrfs_drop_snapshot.
Si
lock_extent, try_lock_extent, and lock_extent_bits can't currently fail
because errors are caught via BUG_ON.
This patch pushes the error handling up to callers, which currently
only handle them via BUG_ON themselves.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/compression.c |3 +-
fs
pin_down_extent performs some operations which can't fail and then calls
set_extent_dirty, which has two failure cases via set_extent_bit:
1) Return -EEXIST if exclusive bits are set
- Since it doesn't use any exclusive bits, this failure case can't
occur.
2) Return -ENOMEM if memory
clear_extent_bit can fail with -ENOMEM for a specific case but will BUG
on other memory allocation failures.
This patch returns -ENOMEM for memory allocation failures and handles them
with BUG_ON in callers which don't handle it already.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/disk-io.c
On tue, 9 Aug 2011 10:46:37 -0700, Sage Weil wrote:
> Fix a crash/BUG_ON in the clone ioctl due to insufficient reservation. We
> need to reserve space for:
>
> - adjusting the old extent (possibly splitting it)
> - adding the new extent
> - updating the inode
>
> Signed-off-by: Sage Weil
> -
Jan,
I personally like the way we interact with the kernel using the
/sys or /proc that's a cool way, mainly because no C code is required.
A generic interface like that (or btrfs-control with more commands
supported) will enhance troubleshooting and debugging, application
interface.
or di
krz...@gmail.com wrote:
> # uname -a
> Linux dhcppc1 3.0.1--std-ipv6-64 #1 SMP Sun Aug 14 17:06:21 CEST
> 2011 x86_64 x86_64 x86_64 GNU/Linux
>
> mkdir test5
> cd test5
> dd if=/dev/null of=img5 bs=1 seek=2G
> dd if=/dev/null of=img6 bs=1 seek=2G
> losetup /dev/loop2 img5
> losetup /dev/loop3
I noticed a series of hung_task notifications in dmesg, so I went
poking at it. Process is 'dropbox', and it's stuck trying to llseek
it's library.zip file.
strace of dropbox:
...
stat("/home/x/.dropbox-dist/library.zip", {st_mode=S_IFREG|0755,
st_size=11575179, ...}) = 0
open("/home/x/.dropbox-
On Tue, 16 Aug 2011, Miao Xie wrote:
> On tue, 9 Aug 2011 10:46:37 -0700, Sage Weil wrote:
> > Fix a crash/BUG_ON in the clone ioctl due to insufficient reservation. We
> > need to reserve space for:
> >
> > - adjusting the old extent (possibly splitting it)
> > - adding the new extent
> > - up
28 matches
Mail list logo
