On Thu, Apr 15, 2021 at 02:36:37PM -0500, Charles Zeitler wrote:
> disks are raid5, i don't know which are /dev/sdb /dev/sdc etc.
> is this going to be an issue?
Nope.
Hugo.
Oh, all right, I'll explain...
The superblock on each device contains the UUID of the filesystem
and
disks are raid5, i don't know which are /dev/sdb /dev/sdc etc.
is this going to be an issue?
charles zeitler
--
The Perfect Is The Enemy Of
The Good Enough
On 2021/03/29 12:34, Anand Jain wrote:
> On 15/03/2021 13:53, Naohiro Aota wrote:
>> The following patch will change the superblock logging zones' location from
>> fixed zone number to fixed LBAs.
>>
>> Here is a background of how the superblock is working on zoned btrfs.
>>
>> This document will b
On 15/03/2021 13:53, Naohiro Aota wrote:
The following patch will change the superblock logging zones' location from
fixed zone number to fixed LBAs.
Here is a background of how the superblock is working on zoned btrfs.
This document will be promoted to btrfs-dev-docs in the future.
# Superblo
The following patch will change the superblock logging zones' location from
fixed zone number to fixed LBAs.
Here is a background of how the superblock is working on zoned btrfs.
This document will be promoted to btrfs-dev-docs in the future.
# Superblock logging for zoned btrfs
The superblock
I wish there are btrfs unmount logs or ctree-close logs so that we can
know if the device was closed during the suspend. Those patches aren't
merged yet.
So here if I guess it correctly, the suspend does not seems to unmount
the filesystem, which means the device open is never closed. And, i
I've moved a drive to a different sata controller during a suspend. Btrfs does
not understand that. I had to give the filesystem a new uuid before I could
access it again. Is there some setting in the kernel so it can deal with this?
Initial mounting of the btrfs partition:
[199167.697831] BTR
From: Filipe Manana
Test that if we move a file from a directory B to a directory A, replace
directory B with directory A, fsync the file and then power fail, after
mounting the filesystem the file has a single parent, named B and there
is no longer any directory with the name A.
This test is mo
[] ? do_unlinkat+0x148/0x330
> Oct 31 15:48:44 wuerfelzucker kernel: [107426.624447]
> [] ? system_call_fast_compare_end+0xc/0x9b
>
> 9h later, the OOM killer kicked in and kept killing processes for
> another 30 minutes, before the logs end. The full log file is found at
>
&g
sacti".
As far as I can tell from the logs, moving the data was finished by
then (at least, I don't see an instance of "mv" in the process list
from the OOM killer). Otherwise, the machine was idle.
If you need any more data for investigating this problem, I might be
able
Adam Borowski posted on Sat, 19 Aug 2017 04:35:26 +0200 as excerpted:
> On Fri, Aug 18, 2017 at 11:09:22PM -0300, Hérikz Nawarro wrote:
>> Hello everyone,
>>
>> Can i create a btrfs fs in a machine and move the disk to another
>> machine like a ext4 or ntfs?
>
> Yeah, no problem whatsoever, even
On Fri, Aug 18, 2017 at 11:09:22PM -0300, Hérikz Nawarro wrote:
> Hello everyone,
>
> Can i create a btrfs fs in a machine and move the disk to another
> machine like a ext4 or ntfs?
Yeah, no problem whatsoever, even for multi-device filesystems.
Btrfs doesn't care about what devices it is on.
T
Hello everyone,
Can i create a btrfs fs in a machine and move the disk to another
machine like a ext4 or ntfs?
Thanks in advance.
--
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.ker
On Thu, Jan 12, 2017 at 03:13:37AM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that an incremental send operation works after moving a directory
> into a new parent directory, deleting its previous parent directory and
> creating a new inode that has the same
From: Filipe Manana
Test that an incremental send operation works after moving a directory
into a new parent directory, deleting its previous parent directory and
creating a new inode that has the same inode number as the old parent.
This issue is fixed by the following patch for the linux
In __btrfs_lookup_bio_sums() we set the file offset value at the
beginning of every iteration of the while loop. This is incorrect since
the blocks mapped by the current bvec->bv_page might not yet have been
completely processed.
This commit fixes the issue by setting the file offset value when we
From: Filipe Manana
Test that an incremental send operation works after doing radical changes
in the directory hierarchy that involve switching the inode that directory
entries point to.
This test exercises scenarios used to fail in btrfs and are fixed by the
following patches for the linux kern
On Tue, Jul 12, 2016 at 4:58 AM, Eryu Guan wrote:
> On Sat, Jul 02, 2016 at 01:32:08PM +0100, fdman...@kernel.org wrote:
>> From: Filipe Manana
>>
>> Test that an incremental send operation works after doing radical changes
>> in the directory hierarchy that involve switching the inode that direc
On Sat, Jul 02, 2016 at 01:32:08PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that an incremental send operation works after doing radical changes
> in the directory hierarchy that involve switching the inode that directory
> entries point to.
>
> This test exercises scenar
From: Filipe Manana
Test that an incremental send operation works after doing radical changes
in the directory hierarchy that involve switching the inode that directory
entries point to.
This test exercises scenarios used to fail in btrfs and are fixed by the
following patches for the linux kern
In __btrfs_lookup_bio_sums() we set the file offset value at the
beginning of every iteration of the while loop. This is incorrect since
the blocks mapped by the current bvec->bv_page might not yet have been
completely processed.
This commit fixes the issue by setting the file offset value when we
In __btrfs_lookup_bio_sums() we set the file offset value at the
beginning of every iteration of the while loop. This is incorrect since
the blocks mapped by the current bvec->bv_page might not yet have been
completely processed.
This commit fixes the issue by setting the file offset value when we
In __btrfs_lookup_bio_sums() we set the file offset value at the
beginning of every iteration of the while loop. This is incorrect since
the blocks mapped by the current bvec->bv_page might not yet have been
completely processed.
This commit fixes the issue by setting the file offset value when we
In __btrfs_lookup_bio_sums() we set the file offset value at the
beginning of every iteration of the while loop. This is incorrect since
the blocks mapped by the current bvec->bv_page might not yet have been
completely processed.
This commit fixes the issue by setting the file offset value when we
In __btrfs_lookup_bio_sums() we set the file offset value at the
beginning of every iteration of the while loop. This is incorrect since
the blocks mapped by the current bvec->bv_page might not yet have been
completely processed.
This commit fixes the issue by setting the file offset value when we
On Wed, Apr 06, 2016 at 11:11:56PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that if we create a hard link for a file F in some directory A,
> then move some directory or file B from its parent directory C into
> directory A, fsync file F, power fail and mount the filesyste
From: Filipe Manana
Test that if we create a hard link for a file F in some directory A,
then move some directory or file B from its parent directory C into
directory A, fsync file F, power fail and mount the filesystem, the
directory/file B is located only at directory A and both links for
file
On Wed, Mar 23, 2016 at 8:08 PM, Ryan Erato wrote:
> Success! Using the same ISO you previously linked to, I ran 'btrfs
> check --repair', did another check which actually revealed many new
> issues, ran a repair again and after that successive checks showed no
> signs of other issues. I was able
Success! Using the same ISO you previously linked to, I ran 'btrfs
check --repair', did another check which actually revealed many new
issues, ran a repair again and after that successive checks showed no
signs of other issues. I was able to successfully send my 'home'
subvolume to the SSD and wow,
On Tue, Mar 22, 2016 at 7:40 PM, Ryan Erato wrote:
> Finally got around to running the suggested commands. Same error with
> the send, but not much output to help. The check operation did seem
> to reveal some potential issues. Here's the play-by-play along with
> the file output from check:
>
>
Finally got around to running the suggested commands. Same error with
the send, but not much output to help. The check operation did seem
to reveal some potential issues. Here's the play-by-play along with
the file output from check:
[liveuser@localhost /]$ sudo btrfs check /dev/sda6 >
/home/live
On Sun, Mar 20, 2016 at 10:34 PM, Ryan Erato wrote:
.
>
> Sending "home.snap" to "/mnt/ssd" results in the -2 error. What is
> peculiar, or possibly a red herring, is that it seems to fail at the
> same point each time, at 4.39GB in to the transfer.
That's pretty suspicious. I didn't realize fr
Here's an example of what I've been trying:
" mount new ssd
root / # mount /dev/sdb6 /mnt/ssd/
" snapshot ROOT sub-volume mounted at /
root / # btrfs subvol snapshot -r / /ROOT.snap
Create a readonly snapshot of '/' in '//ROOT.snap'
root / # btrfs filesystem sync /
FSSync '/'
root / # btrfs sub
I'm not an expert by any means, but I did a migration like this a few weeks ago.
The most consistent recommendation on this mailing list is to use the
newest kernels and btrfs-progs feasible. I did my migration using
Fedora 24 live media, which at the time was kernel ~4.3. I see your
btrfs-progs i
On Sat, Mar 19, 2016 at 4:58 PM, Ryan Erato wrote:
> I'm having quite the time trying to move my current Gentoo install to
> an SSD. I first attempted Clonezilla, but that failed while cloning
> the btrfs partition. I then realized I could use btrfs send/receive.
>
> The partition has 2 subvolumes
I do plan on physically replacing the current drive with the new one
and my fstab/boot comands use device. I never could get UUID or labels
to work, but that's another project.
However, this still leaves me unable to take advantage of btrfs
features for implementing an incremental backup solution
I'm having quite the time trying to move my current Gentoo install to
an SSD. I first attempted Clonezilla, but that failed while cloning
the btrfs partition. I then realized I could use btrfs send/receive.
The partition has 2 subvolumes ROOT and ROOT/home. ROOT snapshots and
sends without hitch,
Am Dienstag, 13. Oktober 2015, 12:39:12 CET schrieben Sie:
> Hi!
>
> With BTRFS to XFS/Ext4 the inode number of the target file stays the same in
> with both cp and mv case (/mnt/zeit is a freshly created XFS in this example):
>
> merkaba:~> ls -li foo /mnt/zeit/moo
> 6609270 foo
> 99 /mn
Hi!
With BTRFS to XFS/Ext4 the inode number of the target file stays the same in
with both cp and mv case (/mnt/zeit is a freshly created XFS in this example):
merkaba:~> ls -li foo /mnt/zeit/moo
6609270 foo
99 /mnt/zeit/moo
merkaba:~> cp foo /mnt/zeit/moo
merkaba:~> ls -li foo /mnt/zeit/
Test file A fsync after moving one other unrelated file B between directories
and fsyncing B's old parent directory before fsyncing the file A. Check that
after a crash all the file A data we fsynced is available.
This test is motivated by an issue discovered in btrfs which caused the file
On Fri, 27 Feb 2015, Filipe David Manana wrote:
> Date: Fri, 27 Feb 2015 10:54:43 +
> From: Filipe David Manana
> To: Lukáš Czerner
> Cc: Filipe Manana , fste...@vger.kernel.org,
> "linux-btrfs@vger.kernel.org"
> Subject: Re: [PATCH] Generic test for f
[PATCH] Generic test for file fsync after moving files across
>> directories
>>
>> Test file fsync after moving one file between directories and fsyncing the
>> old parent directory before fsyncing the file. Verify that after a crash the
>> file data we fsynced is
On Thu, 26 Feb 2015, Filipe Manana wrote:
> Date: Thu, 26 Feb 2015 19:53:14 +
> From: Filipe Manana
> To: fste...@vger.kernel.org
> Cc: linux-btrfs@vger.kernel.org, Filipe Manana
> Subject: [PATCH] Generic test for file fsync after moving files across
> directories
&g
Test file fsync after moving one file between directories and fsyncing the
old parent directory before fsyncing the file. Verify that after a crash the
file data we fsynced is available.
This test is motivated by an issue discovered in btrfs which caused the file
data to be lost (despite fsync
On Fri, Jan 23, 2015 at 5:05 AM, Matthias Urlichs wrote:
> Hello,
>
> how do I move a (read-only) snapshot?
>
If you want to move a read-only snapshot to a different directory,
'..' changes, and therefore is not a read-only operation.
> Simply creating another read-only snap from the first one a
Hello,
how do I move a (read-only) snapshot?
Simply creating another read-only snap from the first one and then deleting
the source works, except that it destroy's the snapshot's identity -- which
means that it can't be used as a parent for "btrfs receive" any more. :-(
--
-- Matthias Urlichs
On Tue, Dec 02, 2014 at 08:41:35PM +0530, Shriramana Sharma wrote:
> That makes sense. Is there anywhere that the "official" SuSE
> recommended subvol layout is mentioned that I can refer to without
> having to start up an installer?
https://www.suse.com/documentation/sles-12/singlehtml/book_sle_a
On Wed, Dec 03, 2014 at 08:02:31AM +0530, Shriramana Sharma wrote:
> On Tue, Dec 2, 2014 at 2:04 PM, Hugo Mills wrote:
> >
> >> Is that correct: what btr sub list shows as "top level" is indeed the
> >> parent subvolume?
> >
> >No, it's the top-level subvolume. (See my earlier mail about
> > n
On Wed, Dec 3, 2014 at 2:43 AM, Austin S Hemmelgarn
wrote:
> Here's my approach to things:
Wow, thanks a lot people! I'm really benefiting from your experience here.
--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
On Tue, Dec 2, 2014 at 2:04 PM, Hugo Mills wrote:
>
>> Is that correct: what btr sub list shows as "top level" is indeed the
>> parent subvolume?
>
>No, it's the top-level subvolume. (See my earlier mail about
> nomenclature). "Parent subvolume" has a number of meanings, none of
> which should
On 2014-12-02 10:11, Shriramana Sharma wrote:
On Tue, Dec 2, 2014 at 6:58 PM, David Sterba wrote:
A subvolume is also a snapshotting barrier, so it's convenient to create
subvolumes in well-known paths that contain data that should not be
rolled back (/var/log, /srv, bootloader).
Hi David --
On 12/02/2014 07:11 AM, Shriramana Sharma wrote:
On Tue, Dec 2, 2014 at 6:58 PM, David Sterba wrote:
A subvolume is also a snapshotting barrier, so it's convenient to create
subvolumes in well-known paths that contain data that should not be
rolled back (/var/log, /srv, bootloader).
That ma
On Tue, Dec 2, 2014 at 6:58 PM, David Sterba wrote:
>
> A subvolume is also a snapshotting barrier, so it's convenient to create
> subvolumes in well-known paths that contain data that should not be
> rolled back (/var/log, /srv, bootloader).
Hi David -- a real honour to meet one of the core Btrf
On Tue, Dec 02, 2014 at 08:51:40AM +0530, Shriramana Sharma wrote:
> > openSUSE uses subvol id 5 for installing the OS to, and some
> > directories are made subvolumes such as home var and maybe usr.
> > Therefore when subvolid 5 is snapshot, those are exempt, and have to
> > be individually snapsh
Shriramana Sharma posted on Tue, 02 Dec 2014 08:51:40 +0530 as excerpted:
> On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy
> wrote:
>>> But isn't it just possible to move i.e. reparent a subvol so I can
>>> move these two under another subvol and have that as default?
>>
>> You can move subvolumes.
On Tue, Dec 02, 2014 at 08:51:40AM +0530, Shriramana Sharma wrote:
> On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy wrote:
> >> But isn't it just possible to move i.e. reparent a
> >> subvol so I can move these two under another subvol and have that as
> >> default?
> >
> > You can move subvolumes.
On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy wrote:
>> But isn't it just possible to move i.e. reparent a
>> subvol so I can move these two under another subvol and have that as
>> default?
>
> You can move subvolumes.
OK so I just found out that just mv test1/foo test2/ where test1,
test2 and fo
On Sat, Nov 29, 2014 at 8:31 PM, Shriramana Sharma wrote:
> So the Ubuntu Wiki BtrFS entry advises against using subvol
> set-default because it boots its kernel using root=subvol=@ and home
> as subvol=@home, and these two subvols are only present under the
> subvol with ID 5.
The advice may hav
On Sun, Nov 30, 2014 at 03:57:06PM +0530, Shriramana Sharma wrote:
> On Sun, Nov 30, 2014 at 9:51 AM, Marc MERLIN wrote:
> >
> >> So the Ubuntu Wiki BtrFS entry advises against using subvol
> >> set-default because it boots its kernel using root=subvol=@ and home
> >> as subvol=@home, and these tw
On Sun, Nov 30, 2014 at 9:23 AM, Shriramana Sharma wrote:
>
>
> Why should noCoW affect cp --reflink anyhow? I just created a 500 MiB
> file from /dev/urandom under a chattr +C-ed dir, and copied to another
> subvol using cp --reflink, and fi df still shows 500 MiB, not 1 GiB.
Looks like I might
On Sun, Nov 30, 2014 at 9:51 AM, Marc MERLIN wrote:
>
>> So the Ubuntu Wiki BtrFS entry advises against using subvol
>> set-default because it boots its kernel using root=subvol=@ and home
>> as subvol=@home, and these two subvols are only present under the
>> subvol with ID 5. But isn't it just p
On Sun, Nov 30, 2014 at 09:01:42AM +0530, Shriramana Sharma wrote:
> So the Ubuntu Wiki BtrFS entry advises against using subvol
> set-default because it boots its kernel using root=subvol=@ and home
> as subvol=@home, and these two subvols are only present under the
> subvol with ID 5. But isn't i
alled as
part of a move operation) and so do a full copy rather than reflink?
Correct me if I'm wrong but it seems that mv should actually ignore
the nocow attribute as far as moving it to a new location is
concerned, no, because I'm moving, not copying? Of course it should
retain the attri
So the Ubuntu Wiki BtrFS entry advises against using subvol
set-default because it boots its kernel using root=subvol=@ and home
as subvol=@home, and these two subvols are only present under the
subvol with ID 5. But isn't it just possible to move i.e. reparent a
subvol so I can move these two unde
ub-volumes (as per the original question) on a
"nearly full" drive you may want to do it all long-hand with a script
moving various chunks or something instead of just trying a move/copy of
"cp --reflinks /vol1/* /vol2/" (same for mv when you get that --reflinks
revision).
On Sat, Nov 29, 2014 at 7:58 PM, Hugo Mills wrote:
>The latest version of mv should be able to use CoW copies to make
> it more efficient. It has a --reflink option, the same as cp. Note
> that you can't make reflinks crossing a mount boundary, but you can do
> so crossing a subvolume boundary
On Sat, Nov 29, 2014 at 07:51:07PM +0530, Shriramana Sharma wrote:
> Hello. I am now taking the first steps to making my backup external
> HDD in BtrFS. From
> http://askubuntu.com/questions/119014/btrfs-subvolumes-vs-folders I
> understand that the only difference between subvolumes and ordinary
>
Hello. I am now taking the first steps to making my backup external
HDD in BtrFS. From
http://askubuntu.com/questions/119014/btrfs-subvolumes-vs-folders I
understand that the only difference between subvolumes and ordinary
folders is that the former can be snapshotted and independently
mounted.
Bu
Moving and deleting cloned ("reflinked") files on btrfs:
- Create a file and a reflink
- Move both to a directory
- Delete the original (moved) file, check that the copy still exists.
[sandeen: mostly cosmetic changes]
Signed-off-by: Koen De Wit
Signed-off-by: Er
I currently have a disk with a btrfs volume dedicated to backups. All
of these backups are snapshotted volumes that were sent to this disk via
btrfs send/receive). Moreover the disk has had deduplication processes
run on it a time or two.
I wish to re-format this disk using a larger metadata blo
On Fri, Dec 13, 2013 at 11:31:47AM -0500, Gene Czarcinski wrote:
> On 12/13/2013 11:07 AM, Gene Czarcinski wrote:
> >I have hunted high and low for the information but, if it is out there,
> >it is well hidden.
> >
> >What I want to do: I want to relocate (move) a subvolume from one BTRFS
> >volum
On Dec 15, 2013, at 10:40 AM, Gene Czarcinski wrote:
> On 12/14/2013 01:43 PM, Chris Murphy wrote:
>> On Dec 14, 2013, at 2:57 AM, Gene Czarcinski wrote:
>>> Since I run Fedora with anaconda I use kickstart installs and can easily
>>> repeat an install since it included almost everything I wa
On 12/14/2013 01:43 PM, Chris Murphy wrote:
On Dec 14, 2013, at 2:57 AM, Gene Czarcinski wrote:
Since I run Fedora with anaconda I use kickstart installs and can easily
repeat an install since it included almost everything I want installed. And
then I have a post-install script I run to pi
On Dec 14, 2013, at 2:57 AM, Gene Czarcinski wrote:
> Since I run Fedora with anaconda I use kickstart installs and can easily
> repeat an install since it included almost everything I want installed. And
> then I have a post-install script I run to pickup additional stuff.
This is a bit of
On 12/14/2013 02:07 AM, Chris Samuel wrote:
On Fri, 13 Dec 2013 02:25:34 PM Gene Czarcinski wrote:
Next it is to delete the old BTRFS volume, use fdisk to increase the
size of the partition and then attempt to increate the size of this new
volume. I hope I don't get bit in the rear end with th
On Fri, 13 Dec 2013 02:25:34 PM Gene Czarcinski wrote:
> Next it is to delete the old BTRFS volume, use fdisk to increase the
> size of the partition and then attempt to increate the size of this new
> volume. I hope I don't get bit in the rear end with this.
Just make sure you have good (test
On 12/13/2013 01:02 PM, Chris Murphy wrote:
On Dec 13, 2013, at 10:37 AM, Cobin Bluth wrote:
That seems a little less intuitive than one would think. I wonder if there
would an argument to specify read-write for btrfs-receive.
I'm going to guess it's on purpose to prevent writes from happen
On Dec 13, 2013, at 10:37 AM, Cobin Bluth wrote:
> That seems a little less intuitive than one would think. I wonder if there
> would an argument to specify read-write for btrfs-receive.
I'm going to guess it's on purpose to prevent writes from happening in the
subvolume while it's still being
On Dec 13, 2013, at 9:31 AM, Gene Czarcinski wrote:
> On 12/13/2013 11:07 AM, Gene Czarcinski wrote:
>> I have hunted high and low for the information but, if it is out there,
>> it is well hidden.
>>
>> What I want to do: I want to relocate (move) a subvolume from one BTRFS
>> volume to a dif
On 12/13/2013 11:07 AM, Gene Czarcinski wrote:
I have hunted high and low for the information but, if it is out there,
it is well hidden.
What I want to do: I want to relocate (move) a subvolume from one BTRFS
volume to a different BTRFS volume.
I have seen the writeup for incremental backup w
I have hunted high and low for the information but, if it is out there,
it is well hidden.
What I want to do: I want to relocate (move) a subvolume from one BTRFS
volume to a different BTRFS volume.
I have seen the writeup for incremental backup which takes a snapshot,
and then using btrfs-
btrfs.nrb posted on Tue, 29 Oct 2013 15:19:19 + as excerpted:
> Hi, I would be pleased to get some help after I have looked and not
> figured out how this should work:
>
> Summary ===
> btrfs device add
> Returns - Inappropriate ioctl for device
> # btrfs --version
> Btrfs Btrfs v0.19
Update:
I found this:
.. by upgrading kernel ...according to the BTRFS wiki, changing raid
levels after the filesystem has been created isn't supported for 3.2
series and older kernels.
Need to move from stable stock., > Ubuntu 12.04LTS and Debian 7.2.
http://serverfault.com/questions/496503/co
Hi, I would be pleased to get some help after I have looked and not
figured out how this should work:
Summary
===
btrfs device add
Returns - Inappropriate ioctl for device
Details
=
// I have an existing btrfs file system
// built from one ~650G partition in middle of 1TB GPT disk,
//
# Moving and deleting cloned ("reflinked") files on btrfs:
# - Create a file and a reflink
# - Move both to a directory
# - Delete the original (moved) file, check that the copy still exists.
[sandeen: mostly cosmetic changes]
Signed-off-by: Koen De Wit
Signed-off-by: Er
Hello,
In an effort to be better about helping users with their bugs I've gotten
control over the btrfs component of bugzilla.kernel.org. I'm currently going
through all the bugs in this list and closing out the old ones (which is most of
them). From now on I'd like us to push users who report b
On 04/02/2013 07:14 PM, Swâmi Petaramesh wrote:
> Le 02/04/2013 19:04, Roman Mamedov a écrit :
>> but at this point I trust my data to BTRFS more, than I would trust ZFS.
>
> My experience with ZFS on Linux is still somewhat limited, the only
> thing that I can say is that I've used it for about 2
Le 03/04/2013 10:47, Uncle Stoatwarbler a écrit :
> my (5 year old) laptop with a relatively slow SSD in it boots to GDM
> (Mint LXDE) in about 5 seconds with ext4. A 9 year old laptop fitted
> with a very slow PATA SSD takes about 9 seconds to do the same.
I've been using Linux daily since 1996,
going on and I feel there must be
some way of merging the good parts of both sets of code, then moving on.
--
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
On Tue, Apr 2, 2013 at 7:14 PM, Swâmi Petaramesh wrote:
> Le 02/04/2013 19:04, Roman Mamedov a écrit :
>> but at this point I trust my data to BTRFS more, than I would trust ZFS.
>
> My experience with ZFS on Linux is still somewhat limited, the only
> thing that I can say is that I've used it for
Le 02/04/2013 19:04, Roman Mamedov a écrit :
> but at this point I trust my data to BTRFS more, than I would trust ZFS.
My experience with ZFS on Linux is still somewhat limited, the only
thing that I can say is that I've used it for about 2 years and a half
on my (quite loaded) home server withou
anywhere.
>
> Did what I could, got the latest kernels, defragged, removed BTRFS
> snapshots, to no avail...
>
> So I'm in process of moving the 3 main laptops in here from BTRFS to ZFS...
Whatever works for you --
but at this point I trust my data to BTRFS more, than I would
ots, to no avail...
So I'm in process of moving the 3 main laptops in here from BTRFS to ZFS...
Kind regards to all.
--
Swâmi Petaramesh http://petaramesh.org PGP 9076E32E
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to major
.0ddb022
>> --- /dev/null
>> +++ b/299
>> @@ -0,0 +1,69 @@
>> +#! /bin/bash
>> +# FS QA Test No. 299
>> +#
>> +# Moving and deleting cloned ("reflinked") files on btrfs:
>> +
On Tue, Jan 15, 2013 at 8:49 AM, Marc MERLIN wrote:
> On Mon, Jan 14, 2013 at 10:48:50PM -0800, David Brown wrote:
>> Why not make a snapshot of the root volume, and then delete the files
>> you want to move from the original root, and delete the rest of root
>> from the snapshot?
>
> Are a snapsh
On Mon, Jan 14, 2013 at 10:48:50PM -0800, David Brown wrote:
> Why not make a snapshot of the root volume, and then delete the files
> you want to move from the original root, and delete the rest of root
> from the snapshot?
Are a snapshot of the root volume and a subvolume effectively the same th
Marc MERLIN writes:
> I made a mistake and copied data in the root of a new btrfs filesystem.
> I created a subvolume, and used mv to put everything in there.
> Something like:
> cd /mnt
> btrfs subvolume create dir
> mv * dir
>
> Except it's been running for over a day now (ok, it's 5TB of data)
On Mon, Jan 14, 2013 at 10:00:41AM -0800, Marc MERLIN wrote:
> On Mon, Jan 14, 2013 at 05:41:55PM +, Hugo Mills wrote:
> > On Mon, Jan 14, 2013 at 09:32:50AM -0800, Marc MERLIN wrote:
> > > I made a mistake and copied data in the root of a new btrfs filesystem.
> > > I created a subvolume, and
On Mon, Jan 14, 2013 at 05:41:55PM +, Hugo Mills wrote:
> On Mon, Jan 14, 2013 at 09:32:50AM -0800, Marc MERLIN wrote:
> > I made a mistake and copied data in the root of a new btrfs filesystem.
> > I created a subvolume, and used mv to put everything in there.
> > Something like:
> > cd /mnt
>
On Mon, Jan 14, 2013 at 09:32:50AM -0800, Marc MERLIN wrote:
> I made a mistake and copied data in the root of a new btrfs filesystem.
> I created a subvolume, and used mv to put everything in there.
> Something like:
> cd /mnt
> btrfs subvolume create dir
> mv * dir
>
> Except it's been running f
1 - 100 of 126 matches
Mail list logo
