Given that ENXIO only means "offset beyond EOF" for either SEEK_DATA or
SEEK_HOLE inquiry
in a desired file range, so we should return the internal error unchanged if
btrfs_get_extent_fiemap()
call failed, rather than ENXIO.
Cc: Dave Chinner
Signed-off-by: Jie Liu
---
fs/btrfs/file.c |4
On 02/09/2012 12:51 PM, Dave Chinner wrote:
> On Thu, Feb 09, 2012 at 12:08:47PM +0800, Jeff Liu wrote:
>> On 02/09/2012 11:46 AM, Jeff Liu wrote:
>>
>>> By referring to http://linux.die.net/man/2/lseek, return ENXIO only
>>> when "offset beyond EOF" for either SEEK_DATA or SEEK_HOLE inquiry.
>>>
As the title shows, we port btrfs online defragments QA test into xfstests.
v1->v2:
- place the real tests inside testcases.
Signed-off-by: Liu Bo
---
278 | 247 ++
278.args | 18 +
278.out | 75 +++
grou
On Thu, Feb 09, 2012 at 12:08:47PM +0800, Jeff Liu wrote:
> On 02/09/2012 11:46 AM, Jeff Liu wrote:
>
> > By referring to http://linux.die.net/man/2/lseek, return ENXIO only
> > when "offset beyond EOF" for either SEEK_DATA or SEEK_HOLE inquiry.
> > But we return it in case of internal issue too i
On 02/09/2012 11:46 AM, Jeff Liu wrote:
> By referring to http://linux.die.net/man/2/lseek, return ENXIO only
> when "offset beyond EOF" for either SEEK_DATA or SEEK_HOLE inquiry.
> But we return it in case of internal issue too if btrfs_get_extent_fiemap()
> failed
> due to other issues. This w
By referring to http://linux.die.net/man/2/lseek, return ENXIO only
when "offset beyond EOF" for either SEEK_DATA or SEEK_HOLE inquiry.
But we return it in case of internal issue too if btrfs_get_extent_fiemap()
failed
due to other issues. This will confuse the user applications to be expecting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/08/2012 06:20 PM, Jan Kara wrote:
> Thanks for your reply. I admit I was not sure what exactly size argument
> should be. So after looking into the code for a while I figured it should
> be a total size of the filesystem - or differently it sho
I've made a little progress here. The rmdir succeeds and successfully
adds the orphan item to the tree. Shortly after that, we (async) snapshot
current/ to snap_127294/. And then the orphan cleanup gets
[87552.240450] [ cut here ]
[87552.240477] WARNING: at
/srv/autob
On 02/09/2012 05:01 AM, Mitch Harder wrote:
> On Wed, Jan 18, 2012 at 10:13 AM, Mitch Harder
> wrote:
>> I have a Btrfs partition that is reliably reproducing premature ENOSPC
>> when restoring the disk from a tar file, but it is only happening with
>> zlib compression (lzo or no compression proce
On 02/09/2012 03:24 AM, Martin wrote:
> My understanding is that for x86 architecture systems, btrfs only allows
> a sector size of 4kB for a HDD/SSD. That is fine for the present HDDs
> assuming the partitions are aligned to a 4kB boundary for that device.
>
> However for SSDs...
>
> I'm using f
On Wed, Feb 8, 2012 at 8:46 PM, Chester wrote:
> On Wed, Feb 8, 2012 at 2:26 PM, Chris Mason wrote:
>> On Wed, Feb 08, 2012 at 01:22:19PM -0600, Chester wrote:
>>> On Wed, Feb 8, 2012 at 6:55 AM, Chris Mason wrote:
>>> > On Tue, Feb 07, 2012 at 06:10:15PM -0600, Chester wrote:
>>> >> This is dme
On Wed 08-02-12 17:01:15, Phillip Susi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 1/26/2012 11:03 AM, Jan Kara wrote:
> > make_btrfs() function takes a size of filesystem as an argument. It
> > uses this value to set the size of the first device as well which
> > is wrong for
On Wed, Feb 8, 2012 at 4:19 PM, Daniel Kuhn wrote:
> After a forced power turn-off the filesystem of my primary boot partition
> cannot be mounted anymore,
> btrfs crashes during the mount process. I'm using OpenSuse 12.1 but I've
> also tried mounting with a newer kernel 3.2.2 (systemrescue cd) a
After a forced power turn-off the filesystem of my primary boot
partition cannot be mounted anymore,
btrfs crashes during the mount process. I'm using OpenSuse 12.1 but I've
also tried mounting with a newer kernel 3.2.2 (systemrescue cd) and with
a usb-converter connected to another PC without s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/26/2012 11:03 AM, Jan Kara wrote:
> make_btrfs() function takes a size of filesystem as an argument. It
> uses this value to set the size of the first device as well which
> is wrong for filesystems larger than this device. It results in
> 'attemp
On Wed, Jan 18, 2012 at 10:13 AM, Mitch Harder
wrote:
> I have a Btrfs partition that is reliably reproducing premature ENOSPC
> when restoring the disk from a tar file, but it is only happening with
> zlib compression (lzo or no compression proceeds normally).
>
> I've had the same issue at least
On Wed, Feb 8, 2012 at 2:26 PM, Chris Mason wrote:
> On Wed, Feb 08, 2012 at 01:22:19PM -0600, Chester wrote:
>> On Wed, Feb 8, 2012 at 6:55 AM, Chris Mason wrote:
>> > On Tue, Feb 07, 2012 at 06:10:15PM -0600, Chester wrote:
>> >> This is dmesg mounted with -o ro,recovery
>> >> [ 20.957392] ex
On Wed, Feb 08, 2012 at 01:22:19PM -0600, Chester wrote:
> On Wed, Feb 8, 2012 at 6:55 AM, Chris Mason wrote:
> > On Tue, Feb 07, 2012 at 06:10:15PM -0600, Chester wrote:
> >> This is dmesg mounted with -o ro,recovery
> >> [ 20.957392] exe used greatest stack depth: 4920 bytes left
> >> [ 145.3
My understanding is that for x86 architecture systems, btrfs only allows
a sector size of 4kB for a HDD/SSD. That is fine for the present HDDs
assuming the partitions are aligned to a 4kB boundary for that device.
However for SSDs...
I'm using for example a 60GByte SSD that has:
8kB page siz
On Wed, Feb 8, 2012 at 6:55 AM, Chris Mason wrote:
> On Tue, Feb 07, 2012 at 06:10:15PM -0600, Chester wrote:
>> This is dmesg mounted with -o ro,recovery
>> [ 20.957392] exe used greatest stack depth: 4920 bytes left
>> [ 145.340317] device label BtrfsLinux devid 1 transid 332442 /dev/sda6
>>
inode_ref_info() returns 1 when the element wasn't found and < 0 on error,
just like btrfs_search_slot(). In iref_to_path() it's an error when the
inode ref can't be found, thus we return ERR_PTR(ret) in that case. In order
to avoid ERR_PTR(1), we now set ret to -ENOENT in that case.
Signed-off-by
On Tue, Feb 07, 2012 at 06:10:15PM -0600, Chester wrote:
> This is dmesg mounted with -o ro,recovery
> [ 20.957392] exe used greatest stack depth: 4920 bytes left
> [ 145.340317] device label BtrfsLinux devid 1 transid 332442 /dev/sda6
> [ 145.341702] btrfs: enabling auto recovery
> [ 145.3418
On Mon, Feb 06, 2012 at 03:35:14PM +, Tommy Faasen wrote:
> I rolled a new kernel 3.2.4 and it picked everything up.
> No crashes, my disk was still full, with 40+ gigs free
> but now I can delete files and access them.
>
> I'm running btrfs fi balance /mountpoint at the moment which I underst
Hi Jan,
Smatch complains when you pass positive numbers to ERR_PTR(). There
is a warning triggered in iref_to_path().
fs/btrfs/backref.c +920 iref_to_path()
918
919 if (ret)
920 return ERR_PTR(ret);
^^^
"ret" can be eith
On 2/8/12 7:41 AM, Chris Samuel wrote:
On Monday 06 February 2012 06:57:42 Hugo Mills wrote:
This al under debian with kernel 2.6.32-5.
Aargh.
You are aware that this is an insanely old version of the brtfs
code, and it has major flaws in it?
As someone who runs his work laptop wi
25 matches
Mail list logo
