no idea what parts of Sun would have survived without a buyer.
Gordon
On Mon, Sep 3, 2018 at 11:22 PM Chris Murphy wrote:
>
> On Mon, Sep 3, 2018 at 7:53 PM, GWB wrote:
> > Curious instance here, but perhaps this is the expected behaviour:
> >
> > mount | grep btrfs
>
Curious instance here, but perhaps this is the expected behaviour:
mount | grep btrfs
/dev/sdb3 on / type btrfs (rw,ssd,subvol=@)
/dev/sdb3 on /home type btrfs (rw,ssd,subvol=@home)
/dev/sde1 on /media/gwb09/btrfs-32G-MicroSDc type btrfs
(rw,nosuid,nodev,uhelper=udisks2)
This is on an Ubuntu 14
Yep, and thank you to Suse, Fujitsu, and all the contributors.
I suppose we can all be charitable when reading this from the Red Hat
Whitepaper at:
https://www.redhat.com/whitepapers/rha/gfs/GFS_INS0032US.pdf:
<<
Red Hat GFS is the world’s leading cluster file system for Linux.
>>
If that is
<<
Or else it could be an argument that they
expect Btrfs to do their job while they watch cat videos from the
intertubes. :-)
>>
My favourite quote from the list this week, and, well, obviously, that
is the main selling point of file systems like btrfs, zfs, and various
other lvm and raid set
Subtle, very subtle.
Gordon
On Fri, Mar 31, 2017 at 9:42 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> GWB posted on Fri, 31 Mar 2017 19:02:40 -0500 as excerpted:
>
>> It is confusing, and now that I look at it, more than a little funny.
>> Your use of xargs returns the size of the
It is confusing, and now that I look at it, more than a little funny.
Your use of xargs returns the size of the kernel module for each of
the filesystem types. I think I get it now: you are pointing to how
large the kernel module for btrfs is compared to other file system
kernel modules, 833 megs
Well, now I am curious. Until we hear back from Christiane on the
progress of the never ending file system shrinkage, I suppose it can't
hurt to ask what the signifigance of the xargs size limits of btrfs
might be. Or, again, if Christiane is already happily on his way to
an xfs server running
Hello, Christiane,
I very much enjoyed the discussion you sparked with your original
post. My ability in btrfs is very limited, much less than the others
who have replied here, so this may not be much help.
Let us assume that you have been able to shrink the device to the size
you need, and you
Michael,
That's great news. Well done. ext4 works just fine for most cases.
If you wish to experiment I might suggest more work on your part (just
what you need, right?) by using btrfs for smaller file systems
(perhaps just root, maybe /var, /bin etc.) but try installing zfs for
large file
e copying. I'm surprised that I didn't end
> up with some corrupted files, but with no files at all.
> Also, I'm not interested in restoring the old Suse 13.2 system. I just
> want some configuration files from it.
>
> Cheers,
> Michael
>
> Am 30.01.2017 um 23:24 schri
<<
Hi btrfs experts.
Hereby I apply for the stupidity of the month award.
>>
I have no doubt that I will will mount a serious challenge to you for
that title, so you haven't won yet.
Why not dd the image back onto the original partition (or another
partition identical in size) and see if that
compatible with the OpenSolaris (and zfs linux) revisions going
forward. "zpool upgrade" on Solaris 11 makes the pool incompatible
with OpenSolaris and zfs-on-linux distros.
Gordon
On Thu, Sep 15, 2016 at 10:26 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> GWB posted on Thu, 15 Sep 201
I don't expect accurate data on a btrfs file system when using df, but
after upgrading to kernel 4.4.0 I get the following:
$ df -i
...
/dev/sdc3 0 0 0 - /home
/dev/sdc4 0 0 0 - /vm0
...
Where /dev/sdc3 and /dev/sdc4 are btrfs
13 matches
Mail list logo
