On Mar 29, 2013, at 9:42 AM, Mitch Harder wrote:
> On Fri, Mar 29, 2013 at 1:21 AM, Chris Murphy wrote:
>>
>> mkfs.btrfs -l 8192 with kernel 3.9.0 creates a file system mountable by
>> 3.9.0 and only 3.9.0 (so far). And while there's no error making such a file
>> system with other kernels,
On 2013/04/03 22:05, Chris Mason wrote:
Quoting Tsutomu Itoh (2013-04-02 21:19:06)
Hi,
When inode_cache was specified for the mount option, I encountered the
following messages at umount.
Step to reproduce:
mkfs.btrfs -f /dev/sdc4
mount -o compress=lzo,autodefrag,inode_cache /dev/sdc4 /te
On 4/3/13 12:31 PM, rjohns...@sgi.com wrote:
> There are duplicate blank lines, comment hash and lines
> containing duplicate seqres= declarations, remove them.
>
> Signed-off-by: Rich Johnston
>
> ---
> tests/btrfs/254 |3 ---
> tests/btrfs/264 |4
> tests/btrfs/265 |3 -
In trying to track down a weird tree log problem I wanted to make sure that the
free space cache was actually valid, which we currently have no way of doing.
So this patch adds a bunch of support for the free space cache code and then a
checker to fsck. Basically we go through and if we can actual
On Wed, Apr 03, 2013 at 04:33:22AM +0200, Harald Glatt wrote:
> However what I actually did was:
> # cd /mnt/restore
> # nc -l -p | btrfs receive .
>
> After noticing this difference I had to try it again as described in
> my mail and - oh wonder - it works now!! Giving 'btrfs receive' a dot
On Wed, Apr 03, 2013 at 06:58:24PM +0200, Goffredo Baroncelli wrote:
> On 04/03/2013 08:22 AM, Anand Jain wrote:
> > Did something break.. ? we are not reporting raid type after balance.
fi df reports exactly what is on the filesystem.
> > ---
> > # btrfs fi df /btrfs
> > Data, RAID0: tot
On 04/03/2013 08:22 AM, Anand Jain wrote:
>
>
> Did something break.. ? we are not reporting raid type after balance.
>
> ---
> # btrfs fi df /btrfs
> Data, RAID0: total=2.00GB, used=2.03MB
> Data: total=8.00MB, used=0.00
> System, RAID0: total=16.00MB, used=4.00KB
> System: total=4.00MB
On 04/02/2013 07:14 PM, Swâmi Petaramesh wrote:
> Le 02/04/2013 19:04, Roman Mamedov a écrit :
>> but at this point I trust my data to BTRFS more, than I would trust ZFS.
>
> My experience with ZFS on Linux is still somewhat limited, the only
> thing that I can say is that I've used it for about 2
On 4/3/13 11:04 AM, Zach Brown wrote:
>>
>> I was wondering if the transaction support should just be in the
>> err: goto case, and went looking.
>
> Yeah, it's tempting. In the end I decided against it because this
> shouldn't be so willing to freak out and make the file system read only.
> It sh
>
> I was wondering if the transaction support should just be in the
> err: goto case, and went looking.
Yeah, it's tempting. In the end I decided against it because this
shouldn't be so willing to freak out and make the file system read only.
It should try and undo the partial unlink and if *tha
On 4/2/13 4:02 PM, Zach Brown wrote:
> __btrfs_unlink_inode() aborts its transaction when it sees errors after
> it removes the directory item. But it missed the case where
> btrfs_del_dir_entries_in_log() returns an error. If this happens then
> the unlink appears to fail but the items have been
Hello,
On a server running Linux kernel 3.8.4-1-ARCH I'm periodically getting
the following warnings (see below) while copying data onto the
filesystem. The setup is btrfs -> LUKS -> md raid5 -> several regular
HDDs. Interested to know if anyone has any info on what might cause this
and wheth
Quoting Tsutomu Itoh (2013-04-02 21:19:06)
> Hi,
>
> When inode_cache was specified for the mount option, I encountered the
> following messages at umount.
>
> Step to reproduce:
>
> mkfs.btrfs -f /dev/sdc4
> mount -o compress=lzo,autodefrag,inode_cache /dev/sdc4 /test1
> dd if=/dev/zero of=/
Using the structure btrfs_sector_sum to keep the checksum value is
unnecessary, because the extents that btrfs_sector_sum points to are
continuous, we can find out the expected checksums by btrfs_ordered_sum's
bytenr and the offset, so we can remove btrfs_sector_sum's bytenr. After
removing bytenr,
Le 03/04/2013 10:47, Uncle Stoatwarbler a écrit :
> my (5 year old) laptop with a relatively slow SSD in it boots to GDM
> (Mint LXDE) in about 5 seconds with ext4. A 9 year old laptop fitted
> with a very slow PATA SSD takes about 9 seconds to do the same.
I've been using Linux daily since 1996,
It is very likely that there are several blocks in bio, it is very
inefficient if we get their csums one by one. This patch improves
this problem by getting the csums in batch.
According to the result of the following test, the execute time of
__btrfs_lookup_bio_sums() is down by ~28%(300us -> 217
On 02/04/13 18:14, Swâmi Petaramesh wrote:
My netbook (now ZFS) boots to GDM in less than 30 seconds. My son's same
machine (except for the FS) takes 75 MORE seconds.
my (5 year old) laptop with a relatively slow SSD in it boots to GDM
(Mint LXDE) in about 5 seconds with ext4. A 9 year old la
On 2013/04/03 10:19, Tsutomu Itoh wrote:
> Hi,
>
> When inode_cache was specified for the mount option, I encountered the
> following messages at umount.
>
> Step to reproduce:
>
> mkfs.btrfs -f /dev/sdc4
> mount -o compress=lzo,autodefrag,inode_cache /dev/sdc4 /test1
> dd if=/dev/zero of=
18 matches
Mail list logo
