[no subject]

subscribe linux-btrfs -- 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-progs and btrfs(8) inconsistencies

On 02/05/2016 11:11 AM, Anand Jain wrote: If you look critically we have been using UI/CLI as API, IMO these two class of interfaces be distinct clearly. Btrfs needs library functions/APIs which is callable in popular scripting language like python. Thanks, Anand +1 too. But

Re: Fi corruption on RAID1, generation doesn't match

On 7 February 2016 at 20:27, Lionel Bouton wrote: > Hi, > > Le 07/02/2016 14:15, Andreas Hild a écrit : >> Dear All, >> >> The file system on a RAID1 Debian server seems corrupted in a major >> way, with 99% of the files not found. This was the result of a >>

Re: Fi corruption on RAID1, generation doesn't match

On 7 February 2016 at 09:27, Qu Wenruo wrote: > > > On 02/07/2016 10:23 PM, Andreas Hild wrote: >> >> On 7 February 2016 at 20:56, Qu Wenruo wrote: >>> >>> >>> You are wondering why data is still 168G, but that's the allocated data >>> chunk size.

Re: Fi corruption on RAID1, generation doesn't match

Hi, Le 07/02/2016 14:15, Andreas Hild a écrit : > Dear All, > > The file system on a RAID1 Debian server seems corrupted in a major > way, with 99% of the files not found. This was the result of a > precarious shutdown after a crash that was preceded by an accidental > misconfiguration in

Fi corruption on RAID1, generation doesn't match

Dear All, The file system on a RAID1 Debian server seems corrupted in a major way, with 99% of the files not found. This was the result of a precarious shutdown after a crash that was preceded by an accidental misconfiguration in /etc/fstab; it pointed "/" and "/tmp" to one and the same UUID by

Re: Fi corruption on RAID1, generation doesn't match

On 7 February 2016 at 20:56, Qu Wenruo wrote: > > You are wondering why data is still 168G, but that's the allocated data > chunk size. > > It means 168G space is allocated to store data, but only 42M is used. > Matches with your vanilla df output. > > So it doesn't mean

Re: Fi corruption on RAID1, generation doesn't match

On 02/07/2016 09:15 PM, Andreas Hild wrote: Dear All, The file system on a RAID1 Debian server seems corrupted in a major way, with 99% of the files not found. This was the result of a precarious shutdown after a crash that was preceded by an accidental misconfiguration in /etc/fstab; it

Re: Fi corruption on RAID1, generation doesn't match

On 02/07/2016 10:23 PM, Andreas Hild wrote: On 7 February 2016 at 20:56, Qu Wenruo wrote: You are wondering why data is still 168G, but that's the allocated data chunk size. It means 168G space is allocated to store data, but only 42M is used. Matches with your

Re: btrfs-progs and btrfs(8) inconsistencies

On 2016-02-07 11:07, Qu Wenruo wrote: > +1 too. > > But first in C, then python wrapper. > > Not sure why there is no such libbtrfs for C wrapper of btrfs ioctls. > > Maybe just because current btrfs ioctl is too easy to use? Unfortunately no. I think the main problem of writing a libbtrfs,

Re: Use fast device only for metadata?

Am Sonntag, 7. Februar 2016, 21:07:13 CET schrieb Kai Krakow: > Am Sun, 07 Feb 2016 11:06:58 -0800 > > schrieb Nikolaus Rath : > > Hello, > > > > I have a large home directory on a spinning disk that I regularly > > synchronize between different computers using unison. That

Re: Use fast device only for metadata?

Am Sun, 07 Feb 2016 11:06:58 -0800 schrieb Nikolaus Rath : > Hello, > > I have a large home directory on a spinning disk that I regularly > synchronize between different computers using unison. That takes ages, > even though the amount of changed files is typically small. I

One disc of 3-disc btrfs-raid5 failed - files only partially readable

Hi, I created a btrfs volume with 3x8TB drives (ST8000AS0002-1NA) in raid5 configuration. I copied some TB of data onto it without errors (from eSATA drives, so rather fast - I mention that because of [1]), then set it up as a fileserver where it had data read and written to it over a gigabit

Use fast device only for metadata?

Hello, I have a large home directory on a spinning disk that I regularly synchronize between different computers using unison. That takes ages, even though the amount of changed files is typically small. I suspect most if the time is spend walking through the file system and checking mtimes. So

Re: Unrecoverable error on raid10

On Sat, Feb 6, 2016 at 5:40 PM, Tom Arild Naess wrote: >>> This is not what I expect from a raid10! >> >> Technically what you don't expect from raid10 is any notification that >> the file may be corrupt at all. It'd be interesting to extract the >> file with restore, and then

Re: suspected BTRFS errors resulting in file system becoming unrecovable

On Tue, Jan 26, 2016 at 5:22 AM, Austin S. Hemmelgarn wrote: > On 2016-01-25 16:12, Chris Murphy wrote: >> I really think USB hubs help fix a lot of USB related problems, even >> when it's not a power related problem. Currently I'm using internal >> SATA in a NUC for the

Re: Use fast device only for metadata?

Martin Steigerwald posted on Sun, 07 Feb 2016 21:59:48 +0100 as excerpted: > Am Sonntag, 7. Februar 2016, 21:07:13 CET schrieb Kai Krakow: >> Am Sun, 07 Feb 2016 11:06:58 -0800 >> >> schrieb Nikolaus Rath : >>> >>> I have a large home directory on a spinning disk that I