On Thu, Dec 1, 2011 at 5:15 AM, 810d4rk <810d...@gmail.com> wrote:
> I plugged it directly by sata and this is what I get from the 3.1 kernel:
> [ 581.921417] sdb: sdb1
> [ 581.921642] sd 2:0:0:0: [sdb] Attached SCSI disk
> [ 660.040263] EXT4-fs (dm-4): VFS: Can't find ext4 filesystem
... and
What can be done about this? Is there anyone able to reproduce the problem?
On 30/11/2011, 810d4rk <810d...@gmail.com> wrote:
> I plugged it directly by sata and this is what I get from the 3.1 kernel:
>
> [ 577.850429] ata3: exception Emask 0x10 SAct 0x0 SErr 0x405
> action 0xe frozen
> [ 5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
While poking around with btrfs-gui I noticed my fs had a fair number of quite
small chunks ( especially metadata ), so I started looking into how they are
allocated. It appears that the current rule is to allocate:
1) At most, 10% of the total fs
Li Zefan wrote:
>
> Nik Markovic wrote:
> > Hi All,
> >
> > I have been encountering consistent btrfs filesystem crashes when
> > using cp –reflink=always on a large file and modifying it. I believe
> > that the test file needs to be fairly large as I was not able to
> > reproduce with smaller file
Nik Markovic wrote:
> Li Zefan wrote:
>>
>> Nik Markovic wrote:
>>> Hi All,
>>>
>>> I have been encountering consistent btrfs filesystem crashes when
>>> using cp –reflink=always on a large file and modifying it. I believe
>>> that the test file needs to be fairly large as I was not able to
>>> rep
Nik Markovic wrote:
> Hi All,
>
> I have been encountering consistent btrfs filesystem crashes when
> using cp –reflink=always on a large file and modifying it. I believe
> that the test file needs to be fairly large as I was not able to
> reproduce with smaller files. The filesystem size is 45GB
Hello!
On Mon, Dec 12, 2011 at 01:30:31AM +0100, David Sterba wrote:
> On Fri, Dec 09, 2011 at 12:39:48PM -0800, Simon Kirby wrote:
> > [ cut here ]
> > WARNING: at mm/page-writeback.c:1763
> > __set_page_dirty_nobuffers+0x17b/0x190()
> > Hardware name: PowerEdge 1950
> >
>You can't change the uuid of an existing btrfs partition. Well, you
>can, but you have to rewrite all the metadata blocks.
Is there a tool that would allow me to rewrite all the metadata blocks with a
new UUID? At this point, it can't possibly take longer than the way I'm trying
to do it now
On Sat, Dec 10, 2011 at 7:22 PM, Li Zefan wrote:
On Thu, Dec 08, 2011 at 11:06:47AM -0800, David Marcin wrote:
> raid10 metadata and data filesystem. dmesg log follows. The system
> is unable to unmount the filesystem after this occurs.
>
> Filesystem mounted at/mnt/btrfs wi
2011/12/12 Alexandre Oliva :
> It was pointed out to me that the test for enough free space in a block
> group was wrong in that it would skip a block group that had most of its
> free space reserved by a cluster.
>
> I offer two mutually exclusive, (so far) very lightly tested patches to
> address
Hi All,
I have been encountering consistent btrfs filesystem crashes when
using cp –reflink=always on a large file and modifying it. I believe
that the test file needs to be fairly large as I was not able to
reproduce with smaller files. The filesystem size is 45GB and file
size is 10GB.
Thanks,
On Mon, Dec 12, 2011 at 03:40:19PM +0100, David Sterba wrote:
> On Tue, Nov 01, 2011 at 11:47:22PM +0200, Ilya Dryomov wrote:
> > --- a/mkfs.c
> > +++ b/mkfs.c
> > @@ -1328,7 +1328,12 @@ int main(int ac, char **av)
> > fprintf(stderr, "error during mkfs %d\n", ret);
> > exit
On Tue, Nov 01, 2011 at 11:47:22PM +0200, Ilya Dryomov wrote:
> --- a/mkfs.c
> +++ b/mkfs.c
> @@ -1328,7 +1328,12 @@ int main(int ac, char **av)
> fprintf(stderr, "error during mkfs %d\n", ret);
> exit(1);
> }
> +
> root = open_ctree(file, 0, O_RDWR);
> +
On 12/11/2011 11:24 AM, Goffredo Baroncelli wrote:
> On Friday, 09 December, 2011 17:40:27 Stefan Behrens wrote:
>> An ioctl interface is added to get the device statistic counters.
>> A second ioctl is added to atomically get and reset these counters.
>
> [...]
>
>>
>> +static long btrfs_ioctl_g
2011/12/12 Alexandre Oliva :
> On Dec 7, 2011, Christian Brunner wrote:
>
>> With this patch applied I get much higher write-io values than without
>> it. Some of the other patches help to reduce the effect, but it's
>> still significant.
>
>> iostat on an unpatched node is giving me:
>
>> Device
15 matches
Mail list logo
