Re: Read-only filesystem

[Qu Wenruo]

 Original Message 
Subject: Read-only filesystem
From: Radosław Kintzi 
To: 
Date: 2014年12月27日 16:01

Hello

The problem:
Every time I start my browser, file system is remounted in read-only
mode.

The cause:
I believe the problem originates from hard reset I had to do.

The details:
# uname -a
Linux tamuz 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC 2014
x86_64
GNU/Linux
# btrfs --version
Btrfs v3.17.3
# btrfs fi show
Label: none  uuid: 98352bc1-7ea6-4801-92b6-944df292b3cd
Total devices 1 FS bytes used 3.17GiB
devid1 size 230.88GiB used 6.04GiB path /dev/sda3

Btrfs v3.17.3
# btrfs fi df /
Data, single: total=4.01GiB, used=3.05GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=1.00GiB, used=119.78MiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=48.00MiB, used=0.00B
# btrfs scrub status /dev/sda3
scrub status for 98352bc1-7ea6-4801-92b6-944df292b3cd
scrub started at Fri Dec 26 19:47:38 2014 and finished after 49 seconds
total bytes scrubbed: 3.29GiB with 1 errors
error details: csum=1
corrected errors: 0, uncorrectable errors: 1, unverified errors: 0

I have attached two logs: dmesg.log.gz - from recent session and
dmesg.log.2.gz - from previous one (search for "WARNING")
Between this two sessions I have done:
# btrfs check --repair

Seems like checksum error.
Would you please also upload the output of btrfsck command and 'btrfsck 
--repair' command
(Although 'btrfsck --repair' won't repair it, so 'btrfsck' output is the 
important)


The questions:

1. How tolerant on power loss is btrfs? Should I expect more problems
like this. Should I expect other problems?

From the design, btrfs should be completely tolerant to sudden power loss.
The cow feature of btrfs should keep btrfs always health if the 
superblock can be write atomicly.


However, btrfs is still under heavy development, bugs deep in the codes 
may makes things nasty anyway.

2. Is there a way to recover the filesystem from  these problems without
restoring whole filesystemi from backup? How to figure out what files
and directories are corrupted? Is it possible to remove corrupted
files/dirs and restore only these from backup?

Hard to say yet, but IMHO it should not be hard to recovery it.
It is not a huge problem like leaf/node corruption in fs tree.

In fact, your dmesg already shows which inode is wrong:
[  282.147037] BTRFS: checksum error at logical 2985828352 on dev 
/dev/sda3, sector 7945232, root 260, inode 509, offset 0, length 4096, 
links 1 (path: radek/.config/google-chrome/Default/Web Data-journal)


Snapshot id 260, inode 509.
But I still perfer the full btrfsck output to make conclusion.

The recovery method may be one of the following:
1) Just remove the file (Web Data-journal) in snapshot 509
I haven't go through the btrfs_unlink() codes, so I'm not sure unlink 
will work or not.

Better to determine it after your btrfsck output to rule out other problems.

2) btrfsck --init-csum-tree
Just rebuild the csum tree, and use the wrong data in the corrupted file.
At least, you know which file is corrupted and you can just recovery it.
Still better to do it after your btrfsck output.

3) None of them fits, need new btrfsck repair function.
If none of above works, I will try to add repair function for btrfsck.

Thanks,
Qu

3. What are general recommendations on using btrfs. Currently (this is
my first experiment with btrfs) I have single partition with subvolumes
mounted as /{,boot,var,opt,home}. I think, it might be better to have more
partiations, but I want to hear from you.

Thaks,
Radosław Kintzi



--
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

Re: fstrim not working on one of three BTRFS filesystems

[Martin Steigerwald]

Am Montag, 29. Dezember 2014, 02:08:21 schrieb Duncan:
> Martin Steigerwald posted on Sun, 28 Dec 2014 17:58:17 +0100 as excerpted:
> 
> > The fstrim on /home returns immediately. It does not even seem to trim
> > anything. What could be the cause for that?
> 
> While I don't know your mapper layout, trim working on the others but not 
> on /home sounds to me like either one of the physical devices on which 
> /home is located doesn't support trim, or they all do, but somewhere 
> along the line that information is being lost, so it doesn't believe trim 
> can actually work on that filesystem.  Typical shortcut "the information 
> available says that can't work, simply return before trying" behavior.

Duncan, it did trim before. Its on two SSDs that definately support trim.

Anyway, I got an hint about it of list with a patch to test.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
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

Re: BTRFS free space handling still needs more work: Hangs again

[Martin Steigerwald]

Am Sonntag, 28. Dezember 2014, 16:27:41 schrieb Robert White:
> On 12/28/2014 07:42 AM, Martin Steigerwald wrote:
> > Am Sonntag, 28. Dezember 2014, 06:52:41 schrieb Robert White:
> >> On 12/28/2014 04:07 AM, Martin Steigerwald wrote:
> >>> Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert White:
>  Now:
> 
>  The complaining party has verified the minimum, repeatable case of
>  simple file allocation on a very fragmented system and the responding
>  party and several others have understood and supported the bug.
> >>>
> >>> I didn´t yet provide such a test case.
> >>
> >> My bad.
> >>
> >>>
> >>> At the moment I can only reproduce this kworker thread using a CPU for
> >>> minutes case with my /home filesystem.
> >>>
> >>> A mininmal test case for me would be to be able to reproduce it with a
> >>> fresh BTRFS filesystem. But yet with my testcase with the fresh BTRFS I
> >>> get 4800 instead of 270 IOPS.
> >>>
> >>
> >> A version of the test case to demonstrate absolutely system-clogging
> >> loads is pretty easy to construct.
> >>
> >> Make a raid1 filesystem.
> >> Balance it once to make sure the seed filesystem is fully integrated.
> >>
> >> Create a bunch of small files that are at least 4K in size, but are
> >> randomly sized. Fill the entire filesystem with them.
> >>
> >> BASH Script:
> >> typeset -i counter=0
> >> while
> >>dd if=/dev/urandom of=/mnt/Work/$((++counter)) bs=$((4096 + $RANDOM))
> >> count=1 2>/dev/null
> >> do
> >> echo $counter >/dev/null #basically a noop
> >> done
> >>
> >> The while will exit when the dd encounters a full filesystem.
> >>
> >> Then delete ~10% of the files with
> >> rm *0
> >>
> >> Run the while loop again, then delete a different 10% with "rm *1".
> >>
> >> Then again with rm *2, etc...
> >>
> >> Do this a few times and with each iteration the CPU usage gets worse and
> >> worse. You'll easily get system-wide stalls on all IO tasks lasting ten
> >> or more seconds.
> >
> > Thanks Robert. Thats wonderful.
> >
> > I wondered about such a test case already and thought about reproducing
> > it just with fallocate calls instead to reduce the amount of actual
> > writes done. I.e. just do some silly fallocate, truncating, write just
> > some parts with dd seek and remove things again kind of workload.
> >
> > Feel free to add your testcase to the bug report:
> >
> > [Bug 90401] New: btrfs kworker thread uses up 100% of a Sandybridge core 
> > for minutes on random write into big file
> > https://bugzilla.kernel.org/show_bug.cgi?id=90401
> >
> > Cause anything that helps a BTRFS developer to reproduce will make it easier
> > to find and fix the root cause of it.
> >
> > I think I will try with this little critter:
> >
> > merkaba:/mnt/btrfsraid1> cat freespracefragment.sh
> > #!/bin/bash
> >
> > TESTDIR="./test"
> > mkdir -p "$TESTDIR"
> >
> > typeset -i counter=0
> > while true; do
> >  fallocate -l $((4096 + $RANDOM)) "$TESTDIR/$((++counter))"
> >  echo $counter >/dev/null #basically a noop
> > done
> 
> If you don't do the remove/delete passes you won't get as much 
> fragmentation...
> 
> I also noticed that fallocate would not actually create the files in my 
> toolset, so I had to touch them first. So the theoretical script became
> 
> e.g.
> 
> typeset -i counter=0
> for AA in {0..9}
> do
>while
>  touch ${TESTDIR}/$((++counter)) &&
>  fallocate -l $((4096 + $RANDOM)) $TESTDIR/$((counter))
>do
>  if ((counter%100 == 0))
>  then
>echo $counter
>  fi
>done
>echo "removing ${AA}"
>rm ${TESTDIR}/*${AA}
> done

Hmmm, strange. It did here. I had a ton of files in the test directory.

> Meanwhile, on my test rig using fallocate did _not_ result in final 
> exhaustion of resources. That is btrfs fi df /mnt/Work didn't show 
> significant changes on a near full expanse.

Hmmm, I had it running up to it allocating about 5 GiB in the data chunks.

But I stopped it yesterday. It took a long time to get there. It seems to be
quite slow on filling a 10 GiB RAID-1 BTRFS. I bet that may be due to lots
of forks for the fallocate command.

But it seems my fallocate works differently than yours. I have fallocate
from:

merkaba:~> fallocate --version
fallocate von util-linux 2.25.2

> I also never got a failed response back from fallocate, that is the 
> inner loop never terminated. This could be a problem with the system 
> call itself or it could be a problem with the application wrapper.

Hmmm, it should return a failure like this:

merkaba:/mnt/btrfsraid1> LANG=C fallocate -l 20G 20g
fallocate: fallocate failed: No space left on device
merkaba:/mnt/btrfsraid1#1> echo $?
1
 
> Nor did I reach the CPU saturation I expected.

No, I didn´t reach it as well. Just 5% or so for the script itself and I
didn´t see any notable kworker activity. But I stopped it before the
filesystem was full, so.

> e.g.
> Gust vm # btrfs fi df /mnt/Work/
> Data, RAID1: total=1.72GiB, used=1.66GiB
> System, RAID1

Re: BTRFS free space handling still needs more work: Hangs again (further tests, as close as I dare, current idea)

[Martin Steigerwald]

Am Sonntag, 28. Dezember 2014, 14:56:21 schrieb Martin Steigerwald:
> Am Sonntag, 28. Dezember 2014, 14:40:32 schrieb Martin Steigerwald:
> > Am Sonntag, 28. Dezember 2014, 14:00:19 schrieb Martin Steigerwald:
> > > Am Samstag, 27. Dezember 2014, 14:55:58 schrieb Martin Steigerwald:
> > > > Summarized at
> > > > 
> > > > Bug 90401 - btrfs kworker thread uses up 100% of a Sandybridge core for 
> > > > minutes on random write into big file
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=90401
> > > > 
> > > > see below. This is reproducable with fio, no need for Windows XP in
> > > > Virtualbox for reproducing the issue. Next I will try to reproduce with
> > > > a freshly creating filesystem.
> > > > 
> > > > 
> > > > Am Samstag, 27. Dezember 2014, 09:30:43 schrieb Hugo Mills:
> > > > > On Sat, Dec 27, 2014 at 10:01:17AM +0100, Martin Steigerwald wrote:
> > > > > > Am Freitag, 26. Dezember 2014, 14:48:38 schrieb Robert White:
> > > > > > > On 12/26/2014 05:37 AM, Martin Steigerwald wrote:
> > > > > > > > Hello!
> > > > > > > > 
> > > > > > > > First: Have a merry christmas and enjoy a quiet time in these 
> > > > > > > > days.
> > > > > > > > 
> > > > > > > > Second: At a time you feel like it, here is a little rant, but 
> > > > > > > > also a
> > > > > > > > bug
> > > > > > > > report:
> > > > > > > > 
> > > > > > > > I have this on 3.18 kernel on Debian Sid with BTRFS Dual SSD 
> > > > > > > > RAID with
> > > > > > > > space_cache, skinny meta data extents – are these a problem? – 
> > > > > > > > and
> > > > > > > 
> > > > > > > > compress=lzo:
> > > > > > > (there is no known problem with skinny metadata, it's actually 
> > > > > > > more
> > > > > > > efficient than the older format. There has been some anecdotes 
> > > > > > > about
> > > > > > > mixing the skinny and fat metadata but nothing has ever been
> > > > > > > demonstrated problematic.)
> > > > > > > 
> > > > > > > > merkaba:~> btrfs fi sh /home
> > > > > > > > Label: 'home'  uuid: b96c4f72-0523-45ac-a401-f7be73dd624a
> > > > > > > > 
> > > > > > > >  Total devices 2 FS bytes used 144.41GiB
> > > > > > > >  devid1 size 160.00GiB used 160.00GiB path
> > > > > > > >  /dev/mapper/msata-home
> > > > > > > >  devid2 size 160.00GiB used 160.00GiB path
> > > > > > > >  /dev/mapper/sata-home
> > > > > > > > 
> > > > > > > > Btrfs v3.17
> > > > > > > > merkaba:~> btrfs fi df /home
> > > > > > > > Data, RAID1: total=154.97GiB, used=141.12GiB
> > > > > > > > System, RAID1: total=32.00MiB, used=48.00KiB
> > > > > > > > Metadata, RAID1: total=5.00GiB, used=3.29GiB
> > > > > > > > GlobalReserve, single: total=512.00MiB, used=0.00B
> > > > > > > 
> > > > > > > This filesystem, at the allocation level, is "very full" (see 
> > > > > > > below).
> > > > > > > 
> > > > > > > > And I had hangs with BTRFS again. This time as I wanted to 
> > > > > > > > install tax
> > > > > > > > return software in Virtualbox´d Windows XP VM (which I use once 
> > > > > > > > a year
> > > > > > > > cause I know no tax return software for Linux which would be 
> > > > > > > > suitable
> > > > > > > > for
> > > > > > > > Germany and I frankly don´t care about the end of security 
> > > > > > > > cause all
> > > > > > > > surfing and other network access I will do from the Linux box 
> > > > > > > > and I
> > > > > > > > only
> > > > > > > > run the VM behind a firewall).
> > > > > > > 
> > > > > > > > And thus I try the balance dance again:
> > > > > > > ITEM: Balance... it doesn't do what you think it does... 
> > > > > > > 
> > > > > > > "Balancing" is something you should almost never need to do. It 
> > > > > > > is only
> > > > > > > for cases of changing geometry (adding disks, switching RAID 
> > > > > > > levels,
> > > > > > > etc.) of for cases when you've radically changed allocation 
> > > > > > > behaviors
> > > > > > > (like you decided to remove all your VM's or you've decided to 
> > > > > > > remove a
> > > > > > > mail spool directory full of thousands of tiny files).
> > > > > > > 
> > > > > > > People run balance all the time because they think they should. 
> > > > > > > They are
> > > > > > > _usually_ incorrect in that belief.
> > > > > > 
> > > > > > I only see the lockups of BTRFS is the trees *occupy* all space on 
> > > > > > the
> > > > > > device.
> > > > >No, "the trees" occupy 3.29 GiB of your 5 GiB of mirrored metadata
> > > > > space. What's more, balance does *not* balance the metadata trees. The
> > > > > remaining space -- 154.97 GiB -- is unstructured storage for file
> > > > > data, and you have some 13 GiB of that available for use.
> > > > > 
> > > > >Now, since you're seeing lockups when the space on your disks is
> > > > > all allocated I'd say that's a bug. However, you're the *only* person
> > > > > who's reported this as a regular occurrence. Does this happen with all
> > > > > filesystems you have, or just this one?
> > > > > 
> > > > > > I *never* so far saw it lockup if the

Re: BTRFS free space handling still needs more work: Hangs again (no complete lockups, "just" tasks stuck for some time)

[Martin Steigerwald]

Am Sonntag, 28. Dezember 2014, 21:07:05 schrieb Zygo Blaxell:
> On Sat, Dec 27, 2014 at 08:23:59PM +0100, Martin Steigerwald wrote:
> > My simple test case didn´t trigger it, and I so not have another twice 160
> > GiB available on this SSDs available to try with a copy of my home
> > filesystem. Then I could safely test without bringing the desktop session to
> > an halt. Maybe someone has an idea on how to "enhance" my test case in
> > order to reliably trigger the issue.
> > 
> > It may be challenging tough. My /home is quite a filesystem. It has a 
> > maildir
> > with at least one million of files (yeah, I am performance testing KMail and
> > Akonadi as well to the limit!), and it has git repos and this one VM image,
> > and the desktop search and the Akonadi database. In other words: It has
> > been hit nicely with various mostly random I think workloads over the last
> > about six months. I bet its not that easy to simulate that. Maybe some runs
> > of compilebench to age the filesystem before the fio test?
> > 
> > That said, BTRFS performs a lot better. The complete lockups without any
> > CPU usage of 3.15 and 3.16 have gone for sure. Thats wonderful. But there
> > is this kworker issue now. I noticed it that gravely just while trying to
> > complete this tax returns stuff with the Windows XP VM. Otherwise it may
> > have happened, I have seen some backtraces in kern.log, but it didn´t last
> > for minutes. So this indeed is of less severity than the full lockups with
> > 3.15 and 3.16.
> > 
> > Zygo, was is the characteristics of your filesystem. Do you use
> > compress=lzo and skinny metadata as well? How are the chunks allocated?
> > What kind of data you have on it?
> 
> compress-force (default zlib), no skinny-metadata.  Chunks are d=single,
> m=dup.  Data is a mix of various desktop applications, most active
> file sizes from a few hundred K to a few MB, maybe 300k-400k files.
> No database or VM workloads.  Filesystem is 100GB and is usually between
> 98 and 99% full (about 1-2GB free).
> 
> I have another filesystem which has similar problems when it's 99.99%
> full (it's 13TB, so 0.01% is 1.3GB).  That filesystem is RAID1 with
> skinny-metadata and no-holes.
> 
> On various filesystems I have the above CPU-burning problem, a bunch of
> irreproducible random crashes, and a hang with a kernel stack that goes
> through SyS_unlinkat and btrfs_evict_inode.

Zygo, thanks. That desktop filesystem sounds a bit similar to my usecase,
with the interesting difference that you have no databases or VMs on it.

That said, I use the Windows XP rarely, but using it was what made the issue
so visible for me. Is your desktop filesystem on SSD?

Do you have the chance to extend one of the affected filesystems to check
my theory that this does not happen as long as BTRFS can still allocate new
data chunks? If its right, your FS should be fluent again as long as you see
more than 1 GiB free

Label: none  uuid: 53bdf47c-4298-45bc-a30f-8a310c274069
Total devices 2 FS bytes used 512.00KiB
devid1 size 10.00GiB used 6.53GiB path /dev/mapper/sata-btrfsraid1
devid2 size 10.00GiB used 6.53GiB path /dev/mapper/msata-btrfsraid1

between "size" and "used" in btrfs fi sh. I suggest going with at least 2-3
GiB, as BTRFS may allocate just one chunk so quickly that you do not have
the chance to recognize the difference.

Well, and if thats works for you, we are back to my recommendation:

More so than with other filesystems give BTRFS plenty of free space to
operate with. At best as much, that you always have a mininum of 2-3 GiB
unused device space for chunk reservation left. One could even do some
Nagios/Icinga monitoring plugin for that :)

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

signature.asc
Description: This is a digitally signed message part.

Re: btrfs doesn't format eMMC if previous filesystem is ext4

[Martin Steigerwald]

Am Montag, 29. Dezember 2014, 07:15:11 schrieb Ankur Tank:

> > -Original Message-
> > From: Anand Jain [mailto:anand.j...@oracle.com]
> > Sent: Monday, December 29, 2014 8:21 AM
> > To: Ankur Tank; linux-btrfs@vger.kernel.org
> > Subject: Re: btrfs doesn't format eMMC if previous filesystem is ext4
> > 
> > On 12/26/2014 11:24 PM, Ankur Tank wrote:
> > > Hi,
> > > 
> > > I wanted to test btrfs on the eMMC of beaglebone black based custom
> > > board.
> > > 
> > > Precondition: eMMC is formatted with ext4 filesystem Use case:
> > >  Format eMMC with mkfs.btrfs  -L
> > > 
> > > Result:
> > >  Mkfs.btrfs denies formatting eMMC because its existing
> > > 
> > > filesystem
> > > 
> > > # mkfs.btrfs -L "1storage" /dev/mmcblk0p2
> > > /dev/mmcblk0p2 appears to contain an existing filesystem (ext4).
> > > Error: Use the -f option to force overwrite.
> > > 
> > > If I add "-f" its possible to format the eMMC.
> > > 
> > > # mkfs.btrfs -f -L "1storage" /dev/mmcblk0p2 Detected a SSD, turning
> > > off metadata duplication.  Mkfs with -m dup if you want to force
> > > metadata duplication. Btrfs v3.17
> > > See http://btrfs.wiki.kernel.org for more information.
> > > 
> > > Performing full device TRIM (1.72GiB) ...
> > > Turning ON incompat feature 'extref': increased hardlink limit per
> > > file to 65536 [273917.692896] btrfs: device label 1storage devid 1
> > > transid 3 /dev/mmcblk0p2 fs created label 1storage on /dev/mmcblk0p2
> > > 
> > >  nodesize 16384 leafsize 16384 sectorsize 4096 size 1.72GiB
> > > 
> > > I had downloaded debian package from following link
> > > https://packages.debian.org/sid/armhf/btrfs-tools/download
> > > 
> > > Is it a bug ? or I am missing something ?
> > > 
> >   I don't see any bug. Can you be more specific ? Thanks.

> Hi Anand,
> 
> Precondition : Previous filesystem on eMMC  was --- ext4
> Use case : Now format eMMC to btrfs format, using ---mkfs.btrfs---
> mkfs.btrfs denies formatting eMMC telling that eMMC contain an existing 
> filesystem(ext4).
> 
> In my opinion mkfs.btrfs must allow to format eMMC with btrfs even if there 
> is other filesystem on it.
> 
> mkfs.ext4 and mkfs.f2fs does allow formatting even if eMMC contains some 
> other file system on it.
> 
> Note: If I add "-f" option mkfs.btrf does allow formatting eMMC to btrfs 
> filesytem.

Thats intended.

It is like mkfs.xfs does it as well.

And I really like this.

Don´t just format an existing filesystem without an explicit request to do
so. I always disliked that on Linux / UNIX tools don´t ask at least once for
dangerous operations. Well some do very toroughly:

merkaba:~> LANG=C apt-get purge bash
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  bash* foomatic-db-engine*
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  bash
0 upgraded, 0 newly installed, 2 to remove and 2 not upgraded.
After this operation, 5887 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?]


Yeah, I know the saying that "root" should know about own actions, yeah I
think alias rm="rm -i" is too much and doesn´t do much good cause people
are motivated to do "rm -f" then to override it after having been asked a
hundred times for each to delete file and if you want, and yeah I think
alias rm="rm -I" or how Z-Shell does it, is much better, but heck we are all
human beings, so I like being warned on actions that may make a ton of data
inaccessible real fast.

So if you want to script it, use "-f". :)

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
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

RE: btrfs doesn't format eMMC if previous filesystem is ext4

[Ankur Tank]

Thank you for reply Anand & Matrin,

Okay I understand the intention now.
I know it's not the forum to address issues related to mkfs commands
But I think, options used should be same across the mkfs.XXX commands.
Another irregularity is
mkfs.f2fs takes "-l" to apply label, while
mkfs.ext4 take  "-L" to apply label.
If one has to write a common script these cases has to be handled separately.

Anyways thank you for help,

Best regards,
Ankur
-Original Message-
From: Martin Steigerwald [mailto:mar...@lichtvoll.de]
Sent: Monday, December 29, 2014 3:09 PM
To: Ankur Tank
Cc: Anand Jain; linux-btrfs@vger.kernel.org
Subject: Re: btrfs doesn't format eMMC if previous filesystem is ext4

Am Montag, 29. Dezember 2014, 07:15:11 schrieb Ankur Tank:

> > -Original Message-
> > From: Anand Jain [mailto:anand.j...@oracle.com]
> > Sent: Monday, December 29, 2014 8:21 AM
> > To: Ankur Tank; linux-btrfs@vger.kernel.org
> > Subject: Re: btrfs doesn't format eMMC if previous filesystem is
> > ext4
> >
> > On 12/26/2014 11:24 PM, Ankur Tank wrote:
> > > Hi,
> > >
> > > I wanted to test btrfs on the eMMC of beaglebone black based
> > > custom board.
> > >
> > > Precondition: eMMC is formatted with ext4 filesystem Use case:
> > >  Format eMMC with mkfs.btrfs  -L
> > >
> > > Result:
> > >  Mkfs.btrfs denies formatting eMMC because its existing
> > >
> > > filesystem
> > >
> > > # mkfs.btrfs -L "1storage" /dev/mmcblk0p2
> > > /dev/mmcblk0p2 appears to contain an existing filesystem (ext4).
> > > Error: Use the -f option to force overwrite.
> > >
> > > If I add "-f" its possible to format the eMMC.
> > >
> > > # mkfs.btrfs -f -L "1storage" /dev/mmcblk0p2 Detected a SSD,
> > > turning off metadata duplication.  Mkfs with -m dup if you want to
> > > force metadata duplication. Btrfs v3.17 See
> > > http://btrfs.wiki.kernel.org for more information.
> > >
> > > Performing full device TRIM (1.72GiB) ...
> > > Turning ON incompat feature 'extref': increased hardlink limit per
> > > file to 65536 [273917.692896] btrfs: device label 1storage devid 1
> > > transid 3 /dev/mmcblk0p2 fs created label 1storage on
> > > /dev/mmcblk0p2
> > >
> > >  nodesize 16384 leafsize 16384 sectorsize 4096 size
> > > 1.72GiB
> > >
> > > I had downloaded debian package from following link
> > > https://packages.debian.org/sid/armhf/btrfs-tools/download
> > >
> > > Is it a bug ? or I am missing something ?
> > >
> >   I don't see any bug. Can you be more specific ? Thanks.

> Hi Anand,
>
> Precondition : Previous filesystem on eMMC  was --- ext4 Use case
> : Now format eMMC to btrfs format, using ---mkfs.btrfs--- mkfs.btrfs
> denies formatting eMMC telling that eMMC contain an existing filesystem(ext4).
>
> In my opinion mkfs.btrfs must allow to format eMMC with btrfs even if there 
> is other filesystem on it.
>
> mkfs.ext4 and mkfs.f2fs does allow formatting even if eMMC contains some 
> other file system on it.
>
> Note: If I add "-f" option mkfs.btrf does allow formatting eMMC to btrfs 
> filesytem.

Thats intended.

It is like mkfs.xfs does it as well.

And I really like this.

Don´t just format an existing filesystem without an explicit request to do so. 
I always disliked that on Linux / UNIX tools don´t ask at least once for 
dangerous operations. Well some do very toroughly:

merkaba:~> LANG=C apt-get purge bash
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  bash* foomatic-db-engine*
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  bash
0 upgraded, 0 newly installed, 2 to remove and 2 not upgraded.
After this operation, 5887 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?]


Yeah, I know the saying that "root" should know about own actions, yeah I think 
alias rm="rm -i" is too much and doesn´t do much good cause people are 
motivated to do "rm -f" then to override it after having been asked a hundred 
times for each to delete file and if you want, and yeah I think alias rm="rm 
-I" or how Z-Shell does it, is much better, but heck we are all human beings, 
so I like being warned on actions that may make a ton of data inaccessible real 
fast.

So if you want to script it, use "-f". :)

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
L&T Technology Services Ltd

www.LntTechservices.com

This Email may contain confidential or privileged information for the intended 
recipient (s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo 

Re: btrfs doesn't format eMMC if previous filesystem is ext4

[Anand Jain]

That's by design. More over this is nothing specific to eMMC.

Thanks.

On 29/12/2014 15:15, Ankur Tank wrote:

Hi Anand,

Precondition : Previous filesystem on eMMC  was --- ext4
Use case : Now format eMMC to btrfs format, using ---mkfs.btrfs---
mkfs.btrfs denies formatting eMMC telling that eMMC contain an existing 
filesystem(ext4).

In my opinion mkfs.btrfs must allow to format eMMC with btrfs even if there is 
other filesystem on it.

mkfs.ext4 and mkfs.f2fs does allow formatting even if eMMC contains some other 
file system on it.

Note: If I add "-f" option mkfs.btrf does allow formatting eMMC to btrfs 
filesytem.

Regards,
Ankur
-Original Message-
From: Anand Jain [mailto:anand.j...@oracle.com]
Sent: Monday, December 29, 2014 8:21 AM
To: Ankur Tank; linux-btrfs@vger.kernel.org
Subject: Re: btrfs doesn't format eMMC if previous filesystem is ext4



On 12/26/2014 11:24 PM, Ankur Tank wrote:

Hi,

I wanted to test btrfs on the eMMC of beaglebone black based custom board.
Precondition: eMMC is formatted with ext4 filesystem Use case:
  Format eMMC with mkfs.btrfs  -L
Result:
  Mkfs.btrfs denies formatting eMMC because its existing
filesystem

# mkfs.btrfs -L "1storage" /dev/mmcblk0p2
/dev/mmcblk0p2 appears to contain an existing filesystem (ext4).
Error: Use the -f option to force overwrite.

If I add "-f" its possible to format the eMMC.

# mkfs.btrfs -f -L "1storage" /dev/mmcblk0p2 Detected a SSD, turning
off metadata duplication.  Mkfs with -m dup if you want to force metadata 
duplication.
Btrfs v3.17
See http://btrfs.wiki.kernel.org for more information.

Performing full device TRIM (1.72GiB) ...
Turning ON incompat feature 'extref': increased hardlink limit per
file to 65536 [273917.692896] btrfs: device label 1storage devid 1
transid 3 /dev/mmcblk0p2 fs created label 1storage on /dev/mmcblk0p2
  nodesize 16384 leafsize 16384 sectorsize 4096 size 1.72GiB

I had downloaded debian package from following link
https://packages.debian.org/sid/armhf/btrfs-tools/download

Is it a bug ? or I am missing something ?

   I don't see any bug. Can you be more specific ? Thanks.


Thank you,

Regards,
Ankur
L&T Technology Services Ltd

www.LntTechservices.com

This Email may contain confidential or privileged information for the intended 
recipient (s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
--
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


L&T Technology Services Ltd

www.LntTechservices.com

This Email may contain confidential or privileged information for the intended 
recipient (s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
--
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


--
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

Re: BTRFS free space handling still needs more work: Hangs again

[Martin Steigerwald]

Am Sonntag, 28. Dezember 2014, 18:04:31 schrieb Patrik Lundquist:
> On 28 December 2014 at 13:03, Martin Steigerwald  wrote:
> >
> > BTW, I found that the Oracle blog didn´t work at all for me. I completed
> > a cycle of defrag, sdelete -c and VBoxManage compact, [...] and it
> > apparently did *nothing* to reduce the size of the file.
> 
> They've changed the argument to -z; sdelete -z.

Now how cute is that. Thank you. This did the trick:

martin@merkaba:~/.VirtualBox/HardDisks> VBoxManage modifyhd Winlala.vdi 
--compact
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
martin@merkaba:~/.VirtualBox/HardDisks> ls -lh
insgesamt 12G
-rw--- 1 martin martin 12G Dez 29 11:00 Winlala.vdi
martin@merkaba:~/.VirtualBox/HardDisks>

It has been 20 GiB before.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
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

Re: btrfs doesn't format eMMC if previous filesystem is ext4

[Martin Steigerwald]

Am Montag, 29. Dezember 2014, 09:55:13 schrieb Ankur Tank:
> Thank you for reply Anand & Matrin,
> 
> Okay I understand the intention now.
> I know it's not the forum to address issues related to mkfs commands
> But I think, options used should be same across the mkfs.XXX commands.
> Another irregularity is
> mkfs.f2fs takes "-l" to apply label, while
> mkfs.ext4 take  "-L" to apply label.
> If one has to write a common script these cases has to be handled separately.
> 
> Anyways thank you for help,

Well, it is *one* of the forums. For that you probably need to CC every
filesystem development mailing list :) or as an alternative the common
fsdevel mailing list.

And yes, mkfs.reiserfs also takes -l. And the mkfs wrapper does *not* convert
the option. So if you use mkfs -t reiserfs -L it doesn´t work. That is why I
always use the mkfs. manpage and tool directly.

I think all mkfs tools should do the blkid check and not overwrite an
existing filesystem just so.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
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

Re: fstrim not working on one of three BTRFS filesystems

[Martin Steigerwald]

Am Sonntag, 28. Dezember 2014, 17:58:17 schrieb Martin Steigerwald:
> Hi!
> 
> After my recent tests with my /home filesystem and the up and downsizing of
> it I get:
> 
> 
> merkaba:~> LANG=C fstrim -v /home
> /home: 0 B (0 bytes) trimmed
> merkaba:~> LANG=C fstrim -v /
> /: 24.5 GiB (26257555456 bytes) trimmed
> merkaba:~> LANG=C fstrim -v /daten
> /daten: 2.8 GiB (3016101888 bytes) trimmed
> 
> 
> The fstrim on /home returns immediately. It does not even seem to trim
> anything. What could be the cause for that?

I have a 3.19-rc2 with a patch and a working fstrim now:

merkaba:~> btrfs scrub status /home
scrub status for […]
scrub started at Mon Dec 29 13:48:17 2014 and finished after 568 seconds
total bytes scrubbed: 272.73GiB with 0 errors

merkaba:~> fstrim -v /home
/home: 18,5 GiB (19873382400 Bytes) getrimmt

merkaba:~> btrfs scrub status /home
scrub status for […]
scrub started at Mon Dec 29 14:02:58 2014 and finished after 576 seconds
total bytes scrubbed: 272.82GiB with 0 errors

merkaba:~> btrfs fi df /home
Data, RAID1: total=139.93GiB, used=133.19GiB
System, RAID1: total=32.00MiB, used=48.00KiB
Metadata, RAID1: total=4.99GiB, used=3.24GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

merkaba:~> LANG=C df -hT /home
Filesystem Type   Size  Used Avail Use% Mounted on
/dev/mapper/msata-home btrfs  170G  137G   32G  82% /home



I wonder about the trimmed size tough:

139,93 - 133,19 = 6,74

4,99 - 3,24 = 1,74

( 6,74 + 1,74 ) * 2 =  16,96 GiB


It is more than whats free inside the chunks but less than the total unused
space. Well it may have been up to what has been allocated as chunks
as I had more chunks allocated in it.


I leave it to the patch author to come up with it on the mailing list :)

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
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

Re: [PATCH] Btrfs: Remove unnecessary placeholder in btrfs_err_code

[David Sterba]

On Wed, Dec 24, 2014 at 02:52:04PM +0900, Satoru Takeuchi wrote:
> I once submit the similar patch to btrfs-progs.
> Then Gui Hecheng tell me fixing original code in kernel
> is better.

The kernel header is exported and the authoritative source for the ioctl
definitions, progs usually copy the required portions but should be
identical in the end.

Reviewed-by: David Sterba 
--
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

Re: [PATCH v2 2/2] btrfs: Enhance btrfs chunk allocation algorithm to reduce ENOSPC caused by unbalanced data/metadata allocation.

[David Sterba]

On Wed, Dec 24, 2014 at 09:55:14AM +0800, Qu Wenruo wrote:
> When btrfs allocate a chunk, it will try to alloc up to 1G for data and
> 256M for metadata, or 10% of all the writeable space if there is enough
> space for the stripe on device.
> 
> However, when we run out of space, this allocation may cause unbalanced
> chunk allocation.
> For example, there are only 1G unallocated space, and request for
> allocate DATA chunk is sent, and all the space will be allocated as data
> chunk, making later metadata chunk alloc request unable to handle, which
> will cause ENOSPC.

The question is why the metadata is full although there's 1G free, as
the metadata chunks are being preallocated according to the metadata
ratio.

> This is the one of the common complains from end users about why ENOSPC
> happens but there is still available space.
> 
> This patch will try not to alloc chunk which is more than half of the
> unallocated space, making the last space more balanced at a small cost
> of more fragmented chunk at the last 1G.

I'm really worried about the small chunks and the fragmentation on that
level wrt balancing. The small chunks will be relolcated to bigger free
chunks (eg. 256mb) and make it unusable for further rebalancing of the
256mb chunks. Newly allocated chunks will have to be reduced in size to
fit in the remaining place and will cause further fragmentation of the
chunk space.

The drawbacks of small chunks are obvious:

* more chunks mean more processing
* smaller chance of getting big contiguous space for extents, leading to
  file fragmentation that cannot be much improved fixed by
  defragmentation

IMO the chunk allocation should be more predictable and should give some
clue how the layout happens, otherwise this will become another dark
corner that would make debugging harder and can negatively and
unpreditactably affect performance after some time.

The problems you're trying to address are real, no doubt here, but I'd
rather try to address them in a different way.
--
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

Re: [PATCH] btrfs: suppress a build warning on building 32bit kernel

[David Sterba]

On Thu, Dec 25, 2014 at 06:21:41PM +0900, Satoru Takeuchi wrote:
> From: Satoru Takeuchi 
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -2190,7 +2190,7 @@ void btrfs_free_io_failure_record(struct inode *inode, 
> u64 start, u64 end)
>   
>   next = next_state(state);
>   
> - failrec = (struct io_failure_record *)state->private;
> + failrec = (struct io_failure_record *)(unsigned 
> long)state->private;

We're always using the 'private' data to store a pointer to
'struct io_failure_record *', please change the defintion in
'struct extent_state' instead of the typecasting.

>   free_extent_state(state);
>   kfree(failrec);
--
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

Re: 3.16.3: fs/btrfs/delayed-inode.c:1410 btrfs_assert_delayed_root_empty

[Chris Mason]

On Sun, Dec 28, 2014 at 4:36 PM, Marc MERLIN  wrote:

On Mon, Dec 29, 2014 at 01:00:47AM +0500, Roman Mamedov wrote:
 > Will btrfs scrub, even if it takes about 24H to run for me, tell 
me

 > which FS is affected and if so do I run btrfs repair?

 I had this: 
https://urldefense.proofpoint.com/v1/url?u=http://www.spinics.net/lists/linux-btrfs/msg40586.html&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=6%2FL0lzzDhu0Y1hL9xm%2BQyA%3D%3D%0A&m=yBJylKLQ0wXzMPYXMMCJaXZfTMrX%2FbRGSoF3t%2FRZsUU%3D%0A&s=9d08d8fb169b6429b819fb9a0c2fda816b4b6c031ee4c5e6ca5a53bb04e3c067


 1) I determined which btrfs of the multiple ones that I have is the 
culprit, by

 unmounting them one by one and seeing if the dmesg spam disappears;


And of course it's the root filesystem on a remote server which I 
can't

service remotely :-/

 3) After that, I ran btrfsck (it did found some errors that looked 
like this,

 repeated dozens of times, with different "root n" numbers):


For the archives, one should use btrfs check --repair directly, 
btrfsck is

dead.

 6) Surprisingly(#2), despite apparently not all of the errors 
having been
 fixed, the btrfs_assert_delayed_root_empty messages no longer 
appear in dmesg.


 The current versions of files mentioned (xfce4-panel.xml and parts 
of the Chromium profile)
 were of course corrupted, but I already noticed that and restored 
them from an earlier snapshot
 even before starting the fsck (yes I also had backups, but didn't 
need them as snapshotted versions

 were fine).


Thanks for the info. I think for now I'll be forced to leave the 
broken

FS run as is and will deal with it when I get home.

Dear btrfs-devs: this is one more example of btrfs having a problem 
with

a non consistent state that ended up on disk.

I got there this way:
- btrfs on top of dmcrypt on top of md raid1 (sorry too many raid bugs
  in btrfs, so I went back to mdadm at the time)
- kernel bug in a serial driver was causing a loop, so I was forced to
  cycle power remotely
- btrfs got broken as per this mail.
- please please please, all warnings and bugs should still be fixed to
  output what device they happened on. Making the admin guess by 
trying

  filesystem one by one isn't really a good way.

Anyway, assuming there isn't a core bug in the btrfs "always 
consistent
state on disk" code, dmcrypt or mdadm prevented a consistent state 
from

reaching the disks.

Separately, I wish I could just fix this while the filesystem is 
online.

btrfs scrub ran totally clean with no errors :(
scrub device /dev/mapper/cryptroot (id 1) done
scrub started at Sun Dec 28 12:07:55 2014 and finished after 
512 seconds

total bytes scrubbed: 25.95GiB with 0 errors

Thankfully the filesystem is still running for now, so it could be 
worse.



I've hit this recently on my laptop, and haven't yet been able to 
recreate it on a machine where I can debug things.  The messages are an 
error in the log tree replay code, and I don't think they are actually 
related to any corruptions.  Trying to nail it down today.


-chris



--
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

Re: 3.16.3: fs/btrfs/delayed-inode.c:1410 btrfs_assert_delayed_root_empty

[Marc MERLIN]

On Mon, Dec 29, 2014 at 10:17:00AM -0500, Chris Mason wrote:
> I've hit this recently on my laptop, and haven't yet been able to
> recreate it on a machine where I can debug things.  The messages are
> an error in the log tree replay code, and I don't think they are
> actually related to any corruptions.  Trying to nail it down today.

Thanks for the update and looking at it.

Just to rule things out for me, on your laptop, are you running btrfs
directly on disk, or do you have layers like dmcrypt in the middle?
(having 2 other layers myself, I never know if it's btrfs that could be
to blame, or the other 2 layers not passing data through in atomic bits
like they're supposed to)

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
--
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

Re: 3.16.3: fs/btrfs/delayed-inode.c:1410 btrfs_assert_delayed_root_empty

[Chris Mason]

On Mon, Dec 29, 2014 at 10:41 AM, Marc MERLIN  wrote:

On Mon, Dec 29, 2014 at 10:17:00AM -0500, Chris Mason wrote:

 I've hit this recently on my laptop, and haven't yet been able to
 recreate it on a machine where I can debug things.  The messages are
 an error in the log tree replay code, and I don't think they are
 actually related to any corruptions.  Trying to nail it down today.


Thanks for the update and looking at it.

Just to rule things out for me, on your laptop, are you running btrfs
directly on disk, or do you have layers like dmcrypt in the middle?
(having 2 other layers myself, I never know if it's btrfs that could 
be
to blame, or the other 2 layers not passing data through in atomic 
bits

like they're supposed to)


I do have dmcrypt, but I really think this is only in btrfs.

-chris



--
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

Re: [PATCH v2] btrfs-progs: Documentation: add T/P/E description for resize cmd

[David Sterba]

On Mon, Dec 22, 2014 at 03:22:53PM +0800, Gui Hecheng wrote:
> Signed-off-by: Gui Hecheng 
> Reviewed-by: Satoru Takeuchi 
> ---
> changelog
>   v1->v2: s/\'E\'(EiB)/or \'E\'(EiB)/ as suggested by Satoru, thanks.
> ---
>  Documentation/btrfs-filesystem.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/btrfs-filesystem.txt 
> b/Documentation/btrfs-filesystem.txt
> index a8f2972..138ba6c 100644
> --- a/Documentation/btrfs-filesystem.txt
> +++ b/Documentation/btrfs-filesystem.txt
> @@ -102,8 +102,8 @@ If the prefix + or - is present the size is increased or 
> decreased
>  by the quantity .
>  If no units are specified, the unit of the  parameter defaults to
>  bytes. Optionally, the size parameter may be suffixed by one of the following
> -units designators: \'K\', \'M', or \'G', kilobytes, megabytes, or gigabytes,
> -respectively.
> +units designators: \'K\'(KiB), \'M\'(MiB), \'G\'(GiB), \'T\'(TiB), \'P\'(PiB)
> +or \'E\'(EiB).

I find this a bit confusing as this would suggest that eg.

  $ btrfs fi resize -1GiB

is valid.
--
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

Re: [PATCH 2/2] btrfs-progs: refine btrfs-debug-tree error prompt when a mount point given

[David Sterba]

On Thu, Dec 25, 2014 at 09:16:35AM +0800, Gui Hecheng wrote:
> Now, if exec:
>   # btrfs-debug-tree 
> it echos:
>   : Superblock bytenr is larger than device size
> 
> But it is quite misleading, because it is a valid btrfs.
> In this case, we should tell the developer to provide a block device.
> 
> After apply:
>   : '' is not a block device
>   : 'usage: btrfs-debug-tree [options] device
> 
> Signed-off-by: Gui Hecheng 
> ---
>  btrfs-debug-tree.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/btrfs-debug-tree.c b/btrfs-debug-tree.c
> index e46500d..7f079a9 100644
> --- a/btrfs-debug-tree.c
> +++ b/btrfs-debug-tree.c
> @@ -179,6 +179,12 @@ int main(int ac, char **av)
>   if (check_argc_exact(ac, 1))
>   print_usage();
>  
> + ret = check_arg_type(av[optind]);
> + if (ret != BTRFS_ARG_BLKDEV) {
> + fprintf(stderr, "'%s' is not a block device\n", av[optind]);
> + print_usage();

The current widespread pattern is to print_usage() after most errors in
commandline arguments but I find it quite annoying. The help is always
available under --help for each command. As the bugfix is good I'm going
to apply it and replace it with exit().

We can start removing misues of print_usage() from the codebase in the
next dev cycle.
--
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

Re: [PATCH 2/2] Capitalize elements in enum for improve readability.

[David Sterba]

On Mon, Dec 22, 2014 at 07:37:59PM +0900, Satoru Takeuchi wrote:
> --- a/send-utils.h
> +++ b/send-utils.h
> @@ -37,10 +37,10 @@ extern "C" {
>  #define BTRFS_COMPAT_SEND_NO_UUID_TREE 1
>  
>  enum subvol_search_type {
> - subvol_search_by_root_id,
> - subvol_search_by_uuid,
> - subvol_search_by_received_uuid,
> - subvol_search_by_path,
> + SUBVOL_SEARCH_BY_ROOT_ID,
> + SUBVOL_SEARCH_BY_UUID,
> + SUBVOL_SEARCH_BY_RECEIVED_UUID,
> + SUBVOL_SEARCH_BY_PATH,

send-utils.h is part of public API, so this would have to be changed in
a backward compatible way, but the current library API is underdesigned
so I don't think this patch will help.

Getting the library right is on the todo list but it will take some time
and some reorganization of sources will have to take place before that.
--
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

Btrfs progs pre-release 3.18-rc3

[David Sterba]

Hi,

there a few more bugfixes that appeared during last week, I did more
testing and am going to release 3.18 tomorrow.

david
--
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

I need to P. are we almost there yet?

[sys.syphus]

specifically (P)arity. very specifically n+2. when will raid5 & raid6
be at least as safe to run as raid1 currently is? I don't like the
idea of being 2 bad drives away from total catastrophe.

(and yes i backup, it just wouldn't be fun to go down that route.)
--
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

Re: I need to P. are we almost there yet?

[sys.syphus]

oh, and sorry to bump myself. but is raid10 *ever* more redundant in
btrfs-speak than raid1? I currently use raid1 but i know in mdadm
speak raid10 means you can lose 2 drives assuming they aren't the
"wrong ones", is it safe to say with btrfs / raid 10 you can only lose
one no matter what?
--
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

Re: I need to P. are we almost there yet?

[Hugo Mills]

On Mon, Dec 29, 2014 at 01:00:05PM -0600, sys.syphus wrote:
> oh, and sorry to bump myself. but is raid10 *ever* more redundant in
> btrfs-speak than raid1? I currently use raid1 but i know in mdadm
> speak raid10 means you can lose 2 drives assuming they aren't the
> "wrong ones", is it safe to say with btrfs / raid 10 you can only lose
> one no matter what?

   I think that with an even number of identical-sized devices, you
get the same "guarantees" (well, behaviour) as you would with
traditional RAID-10.

   I may be wrong about that -- do test before relying on it. The FS
probably won't like losing two devices, though, even if the remaining
data is actually enough to reconstruct the FS.

   Hugo.

-- 
Hugo Mills | I can resist everything except temptation
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: 65E74AC0  |


signature.asc
Description: Digital signature

Re: I need to P. are we almost there yet?

[sys.syphus]

so am I to read that as if btrfs redundancy isn't really functional?
if i yank a member of my raid 1 out in live "prod" is it going to take
a dump on my data?

On Mon, Dec 29, 2014 at 1:04 PM, Hugo Mills  wrote:
> On Mon, Dec 29, 2014 at 01:00:05PM -0600, sys.syphus wrote:
>> oh, and sorry to bump myself. but is raid10 *ever* more redundant in
>> btrfs-speak than raid1? I currently use raid1 but i know in mdadm
>> speak raid10 means you can lose 2 drives assuming they aren't the
>> "wrong ones", is it safe to say with btrfs / raid 10 you can only lose
>> one no matter what?
>
>I think that with an even number of identical-sized devices, you
> get the same "guarantees" (well, behaviour) as you would with
> traditional RAID-10.
>
>I may be wrong about that -- do test before relying on it. The FS
> probably won't like losing two devices, though, even if the remaining
> data is actually enough to reconstruct the FS.
>
>Hugo.
>
> --
> Hugo Mills | I can resist everything except temptation
> hugo@... carfax.org.uk |
> http://carfax.org.uk/  |
> PGP: 65E74AC0  |
--
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

Re: I need to P. are we almost there yet?

[Chris Murphy]

By asking the question this way, I don't think you understand how
Btrfs development works. But if you check out the git pull for 3.19
you'll see a bunch of patches that pretty much close the feature
parity (no pun intended) gap for raid56 and raid0,1,10. But it is an
rc, and still needs testing, and even once 3.19 becomes a stable
kernel it's new enough code there can always be edge cases. And raid1
has been tested in Btrfs for how many years now? So if you want the
same amount of raid6 testing by time it would be however many years
that's been from the time 3.19 is released.

Chris Murphy
--
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

Re: I need to P. are we almost there yet?

[Chris Murphy]

On Mon, Dec 29, 2014 at 12:00 PM, sys.syphus  wrote:
> oh, and sorry to bump myself. but is raid10 *ever* more redundant in
> btrfs-speak than raid1? I currently use raid1 but i know in mdadm
> speak raid10 means you can lose 2 drives assuming they aren't the
> "wrong ones", is it safe to say with btrfs / raid 10 you can only lose
> one no matter what?

It's only for sure one in any case even with conventional raid10. It
just depends on which 2 you lose that depends whether your data has
dodged a bullet. Obviously you can't lose a drive and its mirror,
ever, or the array collapses.

-- 
Chris Murphy
--
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

Re: I need to P. are we almost there yet?

[Hugo Mills]

On Mon, Dec 29, 2014 at 02:25:14PM -0600, sys.syphus wrote:
> so am I to read that as if btrfs redundancy isn't really functional?
> if i yank a member of my raid 1 out in live "prod" is it going to take
> a dump on my data?

   Eh? Where did that conclusion some from? I said nothing at all
about RAID-1, only RAID-10.

   So, to clarify:

   In the general case, you can safely lose one device from a btrfs
RAID-10. Also in the general case, losing a second device will break
the filesystem (with very high probability).

   In the case I gave below, with an even number of equal sized
devices, the second device to be lost *may* allow the data to be
recovered with sufficient effort, but the FS in general will probably
not be mountable with two missing devices.

   So, btrfs RAID-10 offers the same *guarantees* as traditional
RAID-10. It's generally less effective with the probabilities of the
failure modes beyond the guarantee.

   Hugo.

> On Mon, Dec 29, 2014 at 1:04 PM, Hugo Mills  wrote:
> > On Mon, Dec 29, 2014 at 01:00:05PM -0600, sys.syphus wrote:
> >> oh, and sorry to bump myself. but is raid10 *ever* more redundant in
> >> btrfs-speak than raid1? I currently use raid1 but i know in mdadm
> >> speak raid10 means you can lose 2 drives assuming they aren't the
> >> "wrong ones", is it safe to say with btrfs / raid 10 you can only lose
> >> one no matter what?
> >
> >I think that with an even number of identical-sized devices, you
> > get the same "guarantees" (well, behaviour) as you would with
> > traditional RAID-10.
> >
> >I may be wrong about that -- do test before relying on it. The FS
> > probably won't like losing two devices, though, even if the remaining
> > data is actually enough to reconstruct the FS.
> >
> >Hugo.
> >

-- 
Hugo Mills | emacs: Eighty Megabytes And Constantly Swapping.
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: 65E74AC0  |


signature.asc
Description: Digital signature

Re: Uncorrectable errors on RAID-1?

[Chris Murphy]

On Sat, Dec 27, 2014 at 8:12 PM, Phillip Susi  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 12/23/2014 05:09 PM, Chris Murphy wrote:
>> The timer in /sys is a kernel command timer, it's not a device
>> timer even though it's pointed at a block device. You need to
>> change that from 30 to something higher to get the behavior you
>> want. It doesn't really make sense to say, timeout in 30 seconds,
>> but instead of reporting a timeout, report it as a read error.
>> They're completely different things.
>
> The idea is not to give the drive a ridiculous amount of time to
> recover without timing out, but for the timeout to be handled properly.

Get drives supporting configurable or faster recoveries. There's no
way around this.

>
>> There are all sorts of errors listed in libata so for all of them
>> to get dumped into a read error doesn't make sense. A lot of those
>> errors don't report back a sector, and the key part of the read
>> error is what sector(s) have the problem so that they can be fixed.
>> Without that information, the ability to fix it is lost. And it's
>> the drive that needs to report this.
>
> It is not lost.  The information is simply fuzzed from an exact
> individual sector to a range of sectors in the timed out request.  In
> an ideal world the drive would give up in a reasonable time and report
> the failure, but if it doesn't, then we should deal with that in a
> better way than hanging all IO for an unacceptably long time.

This is a broken record topic honestly. The drives under discussion
aren't ever meant to be used in raid, they're desktop drives, they're
designed with long recoveries because it's reasonable to try to
recover the data even in the face of delays rather than not recover at
all. Whether there are also some design flaws in here I can't say
because I'm not a hardware designer or developer but they are very
clearly targeted at certain use cases and not others, not least of
which is their error recovery time but also their vibration tolerance
when multiple drives are in close proximity to each other.

If you don't like long recoveries, don't buy drives with long
recoveries. Simple.


>
>> Oven doesn't work, so lets spray gasoline on it and light it and
>> the kitchen on fire so that we can cook this damn pizza! That's
>> what I just read. Sorry. It doesn't seem like a good idea to me to
>> map all errors as read errors.
>
> How do you conclude that?  In the face of a timeout your choices are
> between kicking the whole drive out of the array immediately, or
> attempting to repair it by recovering the affected sector(s) and
> rewriting them.  Unless that recovery attempt could cause more harm
> than degrading the array, then where is the "throwing gasoline on it"
> part?  This is simply a case of the device not providing a specific
> error that says whether it can be recovered or not, so let's attempt
> the recovery and see if it works instead of assuming that it won't and
> possibly causing data loss that could be avoided.

The device will absolutely provide a specific error so long as its
link isn't reset prematurely, which happens to be the linux default
behavior when combined with drives that have long error recovery
times. Hence the recommendation is to increase the linux command timer
value. That is the solution right now. If you want a different
behavior someone has to write the code to do it because it doesn't
exist yet, and so far there seems to be zero interest in actually
doing that work, just some interest in hand waiving that it ought to
exist, maybe.



>
>> Any decent server SATA drive should support SCT ERC. The
>> inexpensive WDC Red drives for NAS's all have it and by default are
>> a reasonable 70 deciseconds last time I checked.
>
> And yet it isn't supported on the cheaper but otherwise identical
> greens, or the higher performing blues.  We should not be helping
> vendors charge a premium for zero cost firmware features that are
> "required" for raid use when they really aren't ( even if they are
> nice to have ).

The manufacturer says they differ in vibration characteristics, 24x7
usage expectation, and warranty among the top relevant features. The
Red has a 3 year warranty, the Green is a 1 year warranty. That alone
easily accounts for the $15 difference, although that's perhaps
somewhat subjective. I don't actually know the wholesale prices, they
could be the same if the purchasing terms are identical.

Western Digital Red NAS Hard Drive WD30EFRX 3TB IntelliPower 64MB
Cache SATA 6.0Gb/s 3.5" NAS Hard Drive
$114 on Newegg.com

Western Digital WD Green WD30EZRX 3TB IntelliPower 64MB Cache SATA
6.0Gb/s 3.5" Internal Hard Drive Bare Drive - OEM
$99 on Newegg.com

And none of the manufacturers actually says these features are
required for raid use. What they say is, they reserve the right to
deny warranty claims if you're using a drive in a manner inconsistent
with their intended usage which is rather easily found information.

-

Re: I need to P. are we almost there yet?

[ashford]

> On Mon, Dec 29, 2014 at 12:00 PM, sys.syphus  wrote:
>> oh, and sorry to bump myself. but is raid10 *ever* more redundant in
>> btrfs-speak than raid1? I currently use raid1 but i know in mdadm
>> speak raid10 means you can lose 2 drives assuming they aren't the
>> "wrong ones", is it safe to say with btrfs / raid 10 you can only lose
>> one no matter what?
>
> It's only for sure one in any case even with conventional raid10. It
> just depends on which 2 you lose that depends whether your data has
> dodged a bullet. Obviously you can't lose a drive and its mirror,
> ever, or the array collapses.

Just some background data on traditional RAID, and the chances of survival
with a 2-drive failure.

In traditional RAID-10, the chances of surviving a 2-drive failure is 66%
on a 4-drive array, and approaches 100% as the number of drives in the
array increase.

In traditional RAID-0+1 (used to be common in low-end fake-RAID cards),
the chances of surviving a 2-drive failure is 33% on a 4-drive array, and
approaches 50% as the number of drives in the array increase.

In traditional RAID-1E, the chances of surviving a 2-drive failure is 66%
on a 4-drive array, and approaches 100% as the number of drives in the
array increase.  This is the same as for RAID-10.  RAID-1E allows an odd
number of disks to be actively used in the array. 
https://en.wikipedia.org/wiki/File:RAID_1E.png

I'm wondering which of the above the BTRFS implementation most closely
resembles.

> So if you want the same amount of raid6 testing by time it would be
> however many years that's been from the time 3.19 is released.

I don't believe that's correct.  Over those several years, quite a few
tests for corner cases have been developed.  I expect that those tests are
used for regression testing of each release to ensure that old bugs aren't
inadvertently reintroduced.  Furthermore, I expect that a large number of
those corner case tests can be easily modified to test RAID-5 and RAID-6. 
In reality, I expect the stability (i.e. similar to RAID-10 currently) of
RAID-5/6 code in BTRFS will be achieved rather quickly (only a year or
two).

I expect that the difficult part will be to optimize the performance of
BTRFS.  Hopefully those tests (and others, yet to be developed) will be
able to keep it stable while the code is optimized for performance.

Peter Ashford

--
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

Re: [PATCH v2 2/2] btrfs: Enhance btrfs chunk allocation algorithm to reduce ENOSPC caused by unbalanced data/metadata allocation.

[Qu Wenruo]

 Original Message 
Subject: Re: [PATCH v2 2/2] btrfs: Enhance btrfs chunk allocation 
algorithm to reduce ENOSPC caused by unbalanced data/metadata allocation.

From: David Sterba 
To: Qu Wenruo 
Date: 2014年12月29日 22:56

On Wed, Dec 24, 2014 at 09:55:14AM +0800, Qu Wenruo wrote:

When btrfs allocate a chunk, it will try to alloc up to 1G for data and
256M for metadata, or 10% of all the writeable space if there is enough
space for the stripe on device.

However, when we run out of space, this allocation may cause unbalanced
chunk allocation.
For example, there are only 1G unallocated space, and request for
allocate DATA chunk is sent, and all the space will be allocated as data
chunk, making later metadata chunk alloc request unable to handle, which
will cause ENOSPC.

The question is why the metadata is full although there's 1G free, as
the metadata chunks are being preallocated according to the metadata
ratio.
This can still happen after the data chunk is allocated but later only 
heavy metadata workload.



This is the one of the common complains from end users about why ENOSPC
happens but there is still available space.

This patch will try not to alloc chunk which is more than half of the
unallocated space, making the last space more balanced at a small cost
of more fragmented chunk at the last 1G.

I'm really worried about the small chunks and the fragmentation on that
level wrt balancing. The small chunks will be relolcated to bigger free
chunks (eg. 256mb) and make it unusable for further rebalancing of the
256mb chunks. Newly allocated chunks will have to be reduced in size to
fit in the remaining place and will cause further fragmentation of the
chunk space.

The drawbacks of small chunks are obvious:

* more chunks mean more processing
* smaller chance of getting big contiguous space for extents, leading to
   file fragmentation that cannot be much improved fixed by
   defragmentation
You're right, such half-half method will mess up with relocate, that's I 
forgot.


IMO the chunk allocation should be more predictable and should give some
clue how the layout happens, otherwise this will become another dark
corner that would make debugging harder and can negatively and
unpreditactably affect performance after some time.
Some other methods also come to me, like predict the data:metadata ratio 
using current or recent

allocated data:metadata ratio, but it seems not help for the last 1GB case.

Or when it comes to the last 1GB, allocate it as mixed(data+metadata) ?
It seems needs new incompat flags and some tweaks on relocate.

Thanks,
Qu


The problems you're trying to address are real, no doubt here, but I'd
rather try to address them in a different way.


--
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

Re: 3.16.3: fs/btrfs/delayed-inode.c:1410 btrfs_assert_delayed_root_empty

[Qu Wenruo]

 Original Message 
Subject: Re: 3.16.3: fs/btrfs/delayed-inode.c:1410 
btrfs_assert_delayed_root_empty

From: Roman Mamedov 
To: Marc MERLIN 
Date: 2014年12月29日 04:00

On Sun, 28 Dec 2014 11:26:14 -0800
Marc MERLIN  wrote:


Not sure if it's useful to anyone, but there you go. This happened after a 
forced
power cycle:

BTRFS info (device dm-1): disk space caching is enabled
[ cut here ]
WARNING: CPU: 2 PID: 778 at fs/btrfs/delayed-inode.c:1410 
btrfs_assert_delayed_root_empty+0x32/0x34()
Modules linked in: aes_x86_64 lm85 hwmon_vid dm_snapshot dm_bufio iptable_nat 
ip_tables nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_conntrack_ftp 
ipt_MASQUERADE nf_nat x_tables nf_conntrack sg st snd_pcm_oss snd_mixer_oss 
fuse snd_hda_codec_realtek snd_hda_codec_generic microcode snd_cmipci gameport 
snd_hda_intel kvm_intel snd_hda_controller kvm snd_hda_codec snd_opl3_lib 
eeepc_wmi snd_mpu401_uart snd_seq_midi snd_seq_midi_event snd_seq asus_wmi 
battery snd_rawmidi snd_hwdep sparse_keymap rfkill snd_pcm snd_seq_device 
tpm_infineon snd_timer tpm_tis rc_ati_x10 asix coretemp tpm i2c_i801 snd 
processor wmi pl2303 kl5kusb105 libphy ati_remote parport_pc rc_core xhci_hcd 
intel_rapl keyspan ftdi_sio evdev usbnet soundcore pcspkr parport lpc_ich 
intel_powerclamp ezusb usbserial x86_pkg_temp_thermal xts gf128mul dm_crypt 
dm_mod raid456 async_raid6_recov async_pq async_xor async_memcpy async_tx 
e1000e ptp pps_core crc32c_intel crc32_pclmul sata_sil24 thermal 
crct10dif_pclmul eh!

  ci_pci eh
  ci

  _hcd ghash_clmulni_intel r8169 cryptd fan mii usbcore usb_common sata_mv
CPU: 2 PID: 778 Comm: btrfs-transacti Tainted: GW 
3.16.7-amd64-i915-volpreempt-20141114 #1
Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3806 
08/20/2012
   8802117abdc8 816295db 
  8802117abe00 81051e2d 8127038d 880211534000
  880212639980  8802137eaf00 8802117abe10
Call Trace:
  [] dump_stack+0x45/0x56
  [] warn_slowpath_common+0x7f/0x98
  [] ? btrfs_assert_delayed_root_empty+0x32/0x34
  [] warn_slowpath_null+0x1a/0x1c
  [] btrfs_assert_delayed_root_empty+0x32/0x34
  [] btrfs_commit_transaction+0x37f/0x867
  [] transaction_kthread+0xec/0x19f
  [] ? btrfs_cleanup_transaction+0x3f3/0x3f3
  [] kthread+0xae/0xb6
  [] ? __kthread_parkme+0x61/0x61
  [] ret_from_fork+0x7c/0xb0
  [] ? __kthread_parkme+0x61/0x61
---[ end trace 32de13ca415f14fa ]---

I'm now getting this on interval as kernel spam.

It doesn't say which of my 4 btrfs volumes this is linked to, which
doesn't make life easier.

Any idea what I should do from here?

Will btrfs scrub, even if it takes about 24H to run for me, tell me
which FS is affected and if so do I run btrfs repair?

I had this: http://www.spinics.net/lists/linux-btrfs/msg40586.html

1) I determined which btrfs of the multiple ones that I have is the culprit, by
unmounting them one by one and seeing if the dmesg spam disappears;

2) Surprisingly(#1), it was not the one that was heavily operated on in the 
fashion
described in that message;

3) After that, I ran btrfsck (it did found some errors that looked like this,
repeated dozens of times, with different "root n" numbers):

root 22730 inode 97339 errors 200, dir isize wrong
root 22730 inode 4044171 errors 200, dir isize wrong
root 22730 inode 4478553 errors 200, dir isize wrong
root 22730 inode 6236418 errors 2000, link count wrong
 unresolved ref dir 105512 index 586340 namelen 48 name 
[redacted].dat.bak filetype 0 errors 3, no dir item, no dir index
root 22730 inode 6325949 errors 2000, link count wrong
 unresolved ref dir 105512 index 586348 namelen 48 name 
[redacted].dat.bak filetype 0 errors 3, no dir item, no dir index
root 22730 inode 6326136 errors 2000, link count wrong
 unresolved ref dir 105512 index 586344 namelen 48 name 
[redacted].dat.bak filetype 0 errors 3, no dir item, no dir index
root 22730 inode 6326291 errors 2000, link count wrong
 unresolved ref dir 104979 index 192292 namelen 16 name 
downloads.config filetype 0 errors 3, no dir item, no dir index
root 22730 inode 6326292 errors 2000, link count wrong
 unresolved ref dir 4376855 index 19522 namelen 15 name xfce4-panel.xml 
filetype 0 errors 3, no dir item, no dir index
root 22730 inode 6326296 errors 2000, link count wrong
 unresolved ref dir 104979 index 192295 namelen 18 name 
azureus.statistics filetype 0 errors 3, no dir item, no dir index
root 22730 inode 6326380 errors 2000, link count wrong
 unresolved ref dir 4478552 index 45107 namelen 11 name Local State 
filetype 0 errors 3, no dir item, no dir index
root 22730 inode 6326402 errors 2000, link count wrong
 unresolved ref dir 105469 index 233238 namelen 11 name diverse.dat 
filetype 0 errors 3, no dir item, no dir index
root 22730 inode 6326405 errors 2000, link count wrong
 unresolved

Re: [PATCH v2] btrfs-progs: Documentation: add T/P/E description for resize cmd

[Gui Hecheng]

On Mon, 2014-12-29 at 17:07 +0100, David Sterba wrote:
> On Mon, Dec 22, 2014 at 03:22:53PM +0800, Gui Hecheng wrote:
> > Signed-off-by: Gui Hecheng 
> > Reviewed-by: Satoru Takeuchi 
> > ---
> > changelog
> > v1->v2: s/\'E\'(EiB)/or \'E\'(EiB)/ as suggested by Satoru, thanks.
> > ---
> >  Documentation/btrfs-filesystem.txt | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/btrfs-filesystem.txt 
> > b/Documentation/btrfs-filesystem.txt
> > index a8f2972..138ba6c 100644
> > --- a/Documentation/btrfs-filesystem.txt
> > +++ b/Documentation/btrfs-filesystem.txt
> > @@ -102,8 +102,8 @@ If the prefix + or - is present the size is increased 
> > or decreased
> >  by the quantity .
> >  If no units are specified, the unit of the  parameter defaults to
> >  bytes. Optionally, the size parameter may be suffixed by one of the 
> > following
> > -units designators: \'K\', \'M', or \'G', kilobytes, megabytes, or 
> > gigabytes,
> > -respectively.
> > +units designators: \'K\'(KiB), \'M\'(MiB), \'G\'(GiB), \'T\'(TiB), 
> > \'P\'(PiB)
> > +or \'E\'(EiB).
> 
> I find this a bit confusing as this would suggest that eg.
> 
>   $ btrfs fi resize -1GiB
> 
> is valid.

Oh, you're right, thanks for pointing it out, then I'll just follow the
old way and send a new one.

-Gui

> --
> 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


--
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

[PATCH v3] btrfs-progs: Documentation: add T/P/E description for resize cmd

[Gui Hecheng]

Signed-off-by: Gui Hecheng 
Reviewed-by: Satoru Takeuchi 
---
changelog
v1->v2:
s/\'E\'(EiB)/or \'E\'(EiB)/ as suggested by Satoru, thanks.
v2->v3:
replace confusing format 'K'(KiB) etc. Thanks, David.
---
 Documentation/btrfs-filesystem.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/btrfs-filesystem.txt 
b/Documentation/btrfs-filesystem.txt
index a8f2972..96c4420 100644
--- a/Documentation/btrfs-filesystem.txt
+++ b/Documentation/btrfs-filesystem.txt
@@ -102,8 +102,9 @@ If the prefix + or - is present the size is increased or 
decreased
 by the quantity .
 If no units are specified, the unit of the  parameter defaults to
 bytes. Optionally, the size parameter may be suffixed by one of the following
-units designators: \'K\', \'M', or \'G', kilobytes, megabytes, or gigabytes,
-respectively.
+units designators: \'K\', \'M\', \'G\', \'T\', \'P\', or \'E\', which represent
+KiB, MiB, GiB, TiB, PiB, or EiB, respectively.
+
 +
 If \'max' is passed, the filesystem will occupy all available space on the
 device devid.
-- 
1.8.1.4

--
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

RE: btrfs doesn't format eMMC if previous filesystem is ext4

[Ankur Tank]

Martin,

I agree as of now it's better to refer mkfs. manpage and use it 
appropriately.
I will write separate email to fsdevel mailing list.

Thank you,

Regards,
Ankur
-Original Message-
From: Martin Steigerwald [mailto:mar...@lichtvoll.de]
Sent: Monday, December 29, 2014 3:48 PM
To: Ankur Tank
Cc: Anand Jain; linux-btrfs@vger.kernel.org
Subject: Re: btrfs doesn't format eMMC if previous filesystem is ext4

Am Montag, 29. Dezember 2014, 09:55:13 schrieb Ankur Tank:
> Thank you for reply Anand & Matrin,
>
> Okay I understand the intention now.
> I know it's not the forum to address issues related to mkfs commands
> But I think, options used should be same across the mkfs.XXX commands.
> Another irregularity is
> mkfs.f2fs takes "-l" to apply label, while
> mkfs.ext4 take  "-L" to apply label.
> If one has to write a common script these cases has to be handled separately.
>
> Anyways thank you for help,

Well, it is *one* of the forums. For that you probably need to CC every 
filesystem development mailing list :) or as an alternative the common fsdevel 
mailing list.

And yes, mkfs.reiserfs also takes -l. And the mkfs wrapper does *not* convert 
the option. So if you use mkfs -t reiserfs -L it doesn´t work. That is why I 
always use the mkfs. manpage and tool directly.

I think all mkfs tools should do the blkid check and not overwrite an existing 
filesystem just so.

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
L&T Technology Services Ltd

www.LntTechservices.com

This Email may contain confidential or privileged information for the intended 
recipient (s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
--
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