On Sun, 17 Mar 2013, cwillu wrote:
> On Sat, Mar 16, 2013 at 6:46 AM, Russell Coker wrote:
> > On Sat, 16 Mar 2013, cwillu wrote:
> >> On Sat, Mar 16, 2013 at 6:02 AM, Russell Coker
wrote:
> >> > Is it expected that running btrfsck more than once will keep reporting
> >> > errors?
> >>
> >> W
reproducing steps:
mkfs.btrfs /dev/dm-2 -f
mount /dev/dm-2 /btrfs
umount /btrfs
btrfs check /dev/dm-2 --repair
mount /dev/dm-2 /btrfs
btrfs: mismatching generation and generation_v2 found in root item. This root
was probably mounted with an older kernel. Resetting all new fields.
btrfs
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703474
The above Debian bug report has the details of a btrfsck infinite loop problem
I'm having. I initially reported it as an i386 bug because it didn't seem to
appear on AMD64. But then I realised that on AMD64 it merely runs for longer
befo
Hi guys,
After having received strong advice from the people in this list to
upgrade my kernel to the latest one, I have installed 3.8.0-14-generic
#24-Ubuntu SMP x86_64 on several (4) machines.
In the hope of improving systems speed I had also removed all snapshots
then defragged the FSes - the
Hi again,
I wonder if this is the intended behaviour or some known issue?
Otherwise I could provide a tool written by a friend of mine which can
trigger this issue within a few minutes on a a fresh btrfs partition.
Its basically a file-system aging tester, which replays some
real-world logs taken
On Wed, Mar 27, 2013 at 12:28:23AM +0100, Clemens Eisserer wrote:
> I am using a btrfs loopback mounted file with lzo-compression on
> Linux-3.7.9, and I ran into "No space left on device" messages,
> although df reports only 55% of space is used:
>
> # touch testfile
> touch: cannot touch `testfi
We need a mechanism to tell when to use the backup super_block.
To do this it needs a frame-work, and the patch #2 and #3 below
provides the same without change in the logic.
Its been found and posted to the list that check_mounted needs
access to the backup-sb. so patch #3 adds flags parameter
to
Introduce flag BTRFS_SCAN_REGISTER to replace the parameter run_ioctl
which controls calling the function btrfs_register_one_device().
Signed-off-by: Anand Jain
---
cmds-device.c | 4 ++--
disk-io.c | 3 ++-
find-root.c | 3 ++-
utils.c | 17 +
utils.h | 7 +
We should avoid using non multi-path (mp) path for mp disks
As of now there is no good way (like api) to check that.
A workaround way is to check if the O_EXCL open is unsuccessful.
This is safe since otherwise the BTRFS_IOC_SCAN_DEV ioctl would
fail if the disk-path can not be opened with the
except for check_mounted rest of the function thread
should have the access to the backup SB disabled.
this patch will just do that.
Signed-off-by: Anand Jain
---
disk-io.c | 2 +-
find-root.c | 2 +-
utils.c | 2 +-
volumes.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
dif
check_mounted would need to check backup SB to see if the
device is mounted to accommodate the situation when the
primary SB is corrupted (even in multi dev btrfs).
so we need flag to communicate to btrfs_read_dev_super
to check backup SB.
this patch will just introduce the flag with access
to bac
As of now btrfs_read_dev_super() reads the backup super block
by default and calling function has no control. However in the
following patch we would see that is undesirable.
So with the flag BTRFS_SCAN_BACKUP_SB the calling function
can now indicate if btrfs_read_dev_super should scan for
the back
Hi,
Please ignore this patchset.
V2 has been made and will be sent out soon!
The main change is to use quota configurations
on memory to speed up ioctls check.
Thanks,
Wang
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kern
On Wed, Mar 27, 2013 at 09:45:59AM +0800, Zhi Yong Wu wrote:
> HI,
>
> When i work on btrfs hot relocation feature, i hit one question
> about block reservation. btrfs hot relocation need to reserve block
> space from specific devices such as SSD, but current btrfs reserving
> code doesn't dif
On 03/27/2013 10:18 AM, Hugo Mills wrote:
On Wed, Mar 27, 2013 at 12:28:23AM +0100, Clemens Eisserer wrote:
I am using a btrfs loopback mounted file with lzo-compression on
Linux-3.7.9, and I ran into "No space left on device" messages,
although df reports only 55% of space is used:
# touch tes
What do you think; is this issue in the file system can be repaired
with btrfsck? Or should I install a new, patched kernel on my
partition somehow?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Tue, 3 Jul 2012 02:01:21 +0300, Sami Liedes wrote:
> Hi,
>
> I just got this oops on a computer running 3.4.2.
>
> A few minutes before I had started "btrfs device scrub /" and had a
> watcher process running "btrfs scrub status /" every 5 seconds. After
> a few gigabytes of scrubbing, I got t
On Wed, Mar 27, 2013 at 05:51:32AM -0600, Szőts Ákos wrote:
> What do you think; is this issue in the file system can be repaired
> with btrfsck? Or should I install a new, patched kernel on my
> partition somehow?
Sorry I was flipping between your problem and somebody elses problem yesterday
and
All xfstest developers,
Thanks again for all your time in submitting and reviewing patches for
xfstests. The latest patchset posted here:
http://oss.sgi.com/archives/xfs/2013-03/msg00467.html
requires all current patches to be re-factored. Sorry for the inconvenience.
Thanks
--Rich
--
To un
On Wed, Mar 27, 2013 at 08:23:07AM -0500, Rich Johnston wrote:
> All xfstest developers,
>
> Thanks again for all your time in submitting and reviewing patches
> for xfstests. The latest patchset posted here:
>
> http://oss.sgi.com/archives/xfs/2013-03/msg00467.html
>
> requires all current pat
On Wed, Mar 27, 2013 at 7:34 PM, Ilya Dryomov wrote:
> On Wed, Mar 27, 2013 at 09:45:59AM +0800, Zhi Yong Wu wrote:
>> HI,
>>
>> When i work on btrfs hot relocation feature, i hit one question
>> about block reservation. btrfs hot relocation need to reserve block
>> space from specific devices
Extending usage messages with some info on the quota functionality:
- The -i option of "subvol create" and "subvol snapshot" was not
documented
- The -c option of "qgroup limit" is the default option
- The "qouta rescan" command is not yet implemented, while it should be
execut
On Wed, Mar 27, 2013 at 05:51:32AM -0600, Szőts Ákos wrote:
> What do you think; is this issue in the file system can be repaired
> with btrfsck? Or should I install a new, patched kernel on my
> partition somehow?
Ok I've successfully restored your image and I've reproduced your problem, I
will l
Oh, that's a very good news! Thank you very much :)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Hugo,
>> # btrfs filesystem df .
>> Data: total=28.22GB, used=14.25GB
>> System, DUP: total=8.00MB, used=12.00KB
>> System: total=4.00MB, used=0.00
>> Metadata, DUP: total=1.50GB, used=1.16GB
>
>Your metadata is close to full -- we need quite a lot of working
> space to CoW into. You (proba
Hello,
> Extending usage messages with some info on the quota functionality:
>- The -i option of "subvol create" and "subvol snapshot" was not documented
>- The -c option of "qgroup limit" is the default option
>- The "qouta rescan" command is not yet implemented, while it should be
>
On 03/15/2013 11:05 AM, Eric Sandeen wrote:
I think that's big enough change I should send a V2. and
make a btrfs-special case in _defrag_dir.
-Eric
Ping
Did I miss something, I know you are working on several things at once. :)
Thanks
--Rich
--
To unsubscribe from this list: send the line
On Tue, Mar 26, 2013 at 05:28:23PM -0600, Clemens Eisserer wrote:
> Hi,
>
> I am using a btrfs loopback mounted file with lzo-compression on
> Linux-3.7.9, and I ran into "No space left on device" messages,
> although df reports only 55% of space is used:
>
> # touch testfile
> touch: cannot touc
On 03/27/2013 08:46 AM, Theodore Ts'o wrote:
On Wed, Mar 27, 2013 at 08:23:07AM -0500, Rich Johnston wrote:
All xfstest developers,
Thanks again for all your time in submitting and reviewing patches
for xfstests. The latest patchset posted here:
http://oss.sgi.com/archives/xfs/2013-03/msg0046
I just setup a new SSD with my laptop root filesystem, and at the time I
though, "eh, I'll just use zlib compression during the first copy, and then
switch to lzo afterwards to maintain write speed when I'm using the laptop
after the copy and reboot".
Now, I rebooted with the new ssd and zlib comp
On Tue, Mar 26, 2013 at 08:33:27AM -0600, Szőts Ákos wrote:
> Dear list members,
>
> In my previous thread at
> http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg2.html
> there was a space_cache kernel bug/panic on kernel 3.8. I could
> successfully "fix" that with rebuilding the cach
What do you think about renaming the existing tests from NNN to
NNN-descriptive-name? That way it will be easier for people who are
trying to track regressions, since they can easily map from the new
more descriptive name to the old test number for comparison purposes
(i.e., to see whether a failu
I ran two different versions of btrfsck on the partition.
The first one was shipped with openSUSE 12.3, kernel 3.7.
This is the original tool with which the partition was checked:
http://paste.opensuse.org/74569620
The second one is from your tree (maybe it's newer):
http://filebin.ca/bfbwJezYwCV
On Wed, Mar 27, 2013 at 01:17:56PM -0600, Szőts Ákos wrote:
> I ran two different versions of btrfsck on the partition.
>
> The first one was shipped with openSUSE 12.3, kernel 3.7.
> This is the original tool with which the partition was checked:
> http://paste.opensuse.org/74569620
>
> The seco
On Wed, Mar 27, 2013 at 03:05:12PM -0400, Theodore Ts'o wrote:
> What do you think about renaming the existing tests from NNN to
> NNN-descriptive-name? That way it will be easier for people who are
> trying to track regressions, since they can easily map from the new
> more descriptive name to th
Previously btrfs-image would set a METADUMP flag and would make one big system
chunk to cover the entire file system in the super in order to get around the
unpleasant business of having to adjust the chunk tree. This meant that you
could use the progs stuff on a restored file system, which is gre
On Wed, Mar 27, 2013 at 01:17:56PM -0600, Szőts Ákos wrote:
> I ran two different versions of btrfsck on the partition.
>
> The first one was shipped with openSUSE 12.3, kernel 3.7.
> This is the original tool with which the partition was checked:
> http://paste.opensuse.org/74569620
>
> The seco
Hey,
On Wed, Mar 27, 2013 at 01:42:17PM -0700, Zach Brown wrote:
> On Wed, Mar 27, 2013 at 03:05:12PM -0400, Theodore Ts'o wrote:
> > What do you think about renaming the existing tests from NNN to
> > NNN-descriptive-name? That way it will be easier for people who are
> > trying to track regress
On Wed, Mar 27, 2013 at 03:05:12PM -0400, Theodore Ts'o wrote:
> What do you think about renaming the existing tests from NNN to
> NNN-descriptive-name? That way it will be easier for people who are
> trying to track regressions, since they can easily map from the new
> more descriptive name to th
On Wed, Mar 27, 2013 at 09:46:06AM -0400, Theodore Ts'o wrote:
> On Wed, Mar 27, 2013 at 08:23:07AM -0500, Rich Johnston wrote:
> > All xfstest developers,
> >
> > Thanks again for all your time in submitting and reviewing patches
> > for xfstests. The latest patchset posted here:
> >
> > http:/
On Wed, Mar 27, 2013 at 11:53 AM, Marc MERLIN wrote:
>
> Is my feeling of slower boot wrong, or is zlib also noticeably slower than
> lzo to read and decompress?
>
Lzo compression should be faster in every aspect than zlib, especially
for reading.
But having said that, btrfs won't recompress any
On Wed, Mar 27, 2013 at 04:12:27PM -0500, Mitch Harder wrote:
> On Wed, Mar 27, 2013 at 11:53 AM, Marc MERLIN wrote:
> >
> > Is my feeling of slower boot wrong, or is zlib also noticeably slower than
> > lzo to read and decompress?
> >
>
> Lzo compression should be faster in every aspect than zli
On Wed, Mar 27, 2013 at 04:12:27PM -0500, Mitch Harder wrote:
> Lzo compression should be faster in every aspect than zlib, especially
> for reading.
Speaking of which, it would be awesome if there were a some chattr option to
choose which encryption you'd like for a file or a subdirectory tree
(c
On Wed, Mar 27, 2013 at 4:22 PM, Marc MERLIN wrote:
> On Wed, Mar 27, 2013 at 04:12:27PM -0500, Mitch Harder wrote:
>> On Wed, Mar 27, 2013 at 11:53 AM, Marc MERLIN wrote:
>> >
>> > Is my feeling of slower boot wrong, or is zlib also noticeably slower than
>> > lzo to read and decompress?
>> >
>>
I ran btrfsck three times and tried to restart the OS. After a generation_v2
resetting it booted and now it works! :)
Thank you very much for your help!
Two btrfsck run was needed for the complete cleanup, but interestingly the end
statistics were a little bit different each time.
Specificall
On Thu, Mar 28, 2013 at 07:54:07AM +1100, Dave Chinner wrote:
>
> Support for named tests have not yet been added. From the check
> script:
>
> SUPPORTED_TESTS="[0-9][0-9][0-9] [0-9][0-9][0-9][0-9]"
Ah, I thought support for named tests was there. For right now,
though, if we have test ext4/123
Any review comments on this ? pls.
Thanks, Anand
On 27/03/2013 18:07, Anand Jain wrote:
We need a mechanism to tell when to use the backup super_block.
To do this it needs a frame-work, and the patch #2 and #3 below
provides the same without change in the logic.
Its been found and posted to
On Wed, Mar 27, 2013 at 01:42:17PM -0700, Zach Brown wrote:
> On Wed, Mar 27, 2013 at 03:05:12PM -0400, Theodore Ts'o wrote:
> > What do you think about renaming the existing tests from NNN to
> > NNN-descriptive-name? That way it will be easier for people who are
> > trying to track regressions,
On Wed, Mar 27, 2013 at 05:48:04PM -0400, Theodore Ts'o wrote:
> On Thu, Mar 28, 2013 at 07:54:07AM +1100, Dave Chinner wrote:
> >
> > Support for named tests have not yet been added. From the check
> > script:
> >
> > SUPPORTED_TESTS="[0-9][0-9][0-9] [0-9][0-9][0-9][0-9]"
>
> Ah, I thought supp
On Wed, Mar 27, 2013 at 4:56 AM, Swâmi Petaramesh wrote:
> After having received strong advice from the people in this list to
> upgrade my kernel to the latest one, I have installed 3.8.0-14-generic
> #24-Ubuntu SMP x86_64 on several (4) machines.
>
> In the hope of improving systems speed I had
50 matches
Mail list logo
