1 |
Rich Freeman <rich0@g.o> writes: |
2 |
|
3 |
> On Sun, Jan 11, 2015 at 8:14 AM, lee <lee@××××××××.de> wrote: |
4 |
>> Rich Freeman <rich0@g.o> writes: |
5 |
>>> |
6 |
>>> Doing backups with dd isn't terribly practical, but it is completely |
7 |
>>> safe if done correctly. The LV would need to be the same size or |
8 |
>>> larger, or else your filesystem will be truncated. |
9 |
>> |
10 |
>> Yes, my impression is that it isn't very practical or a good method, and |
11 |
>> I find it strange that LVM is still lacking some major features. |
12 |
> |
13 |
> Generally you do backup at the filesystem layer, not at the volume |
14 |
> management layer. LVM just manages a big array of disk blocks. It |
15 |
> has no concept of files. |
16 |
|
17 |
That may require downtime while the idea of taking snapshots and then |
18 |
backing up the volume is to avoid the downtime. |
19 |
|
20 |
>>> Just create a small boot partition and give the rest to zfs. A |
21 |
>>> partition is a block device, just like a disk. ZFS doesn't care if it |
22 |
>>> is managing the entire disk or just a partition. |
23 |
>> |
24 |
>> ZFS does care: You cannot export ZFS pools residing on partitions, and |
25 |
>> apparently ZFS cannot use the disk cache as efficiently when it uses |
26 |
>> partitions. |
27 |
> |
28 |
> Cite? This seems unlikely. |
29 |
|
30 |
,---- [ man zpool ] |
31 |
| For pools to be portable, you must give the zpool command |
32 |
| whole disks, not just partitions, so that ZFS can label the |
33 |
| disks with portable EFI labels. Otherwise, disk drivers on |
34 |
| platforms of different endianness will not recognize the |
35 |
| disks. |
36 |
`---- |
37 |
|
38 |
You may be able to export them, and then you don't really know what |
39 |
happens when you try to import them. I didn't keep a bookmark for the |
40 |
article that mentioned the disk cache. |
41 |
|
42 |
When you read about ZFS, you'll find that using the whole disk is |
43 |
recommended while using partitions is not. |
44 |
|
45 |
>> Caching in memory is also less efficient because another |
46 |
>> file system has its own cache. |
47 |
> |
48 |
> There is no other filesystem. ZFS is running on bare metal. It is |
49 |
> just pointing to a partition on a drive (an array of blocks) instead |
50 |
> of the whole drive (an array of blocks). The kernel does not cache |
51 |
> partitions differently from drives. |
52 |
|
53 |
How do you use a /boot partition that doesn't have a file system? |
54 |
|
55 |
>> On top of that, you have the overhead of |
56 |
>> software raid for that small partition unless you can dedicate |
57 |
>> hardware-raided disks for /boot. |
58 |
> |
59 |
> Just how often are you reading/writing from your boot partition? You |
60 |
> only read from it at boot time, and you only write to it when you |
61 |
> update your kernel/etc. There is no requirement for it to be raided |
62 |
> in any case, though if you have multiple disks that wouldn't hurt. |
63 |
|
64 |
If you want to accept that the system goes down or has to be brought |
65 |
down or is unable to boot because the disk you have your /boot partition |
66 |
on has failed, you may be able to get away with a non-raided /boot |
67 |
partition. |
68 |
|
69 |
When you do that, what's the advantage other than saving the software |
70 |
raid? You still need to either dedicate a disk to it, or you have to |
71 |
leave a part of all the other disks unused and cannot use them as a |
72 |
whole for ZFS because otherwise they will be of different sizes. |
73 |
|
74 |
>>> This sort of thing was very common before grub2 started supporting |
75 |
>>> more filesystems. |
76 |
>> |
77 |
>> That doesn't mean it's a good setup. I'm finding it totally |
78 |
>> undesirable. Having a separate /boot partition has always been a |
79 |
>> crutch. |
80 |
> |
81 |
> Better not buy an EFI motherboard. :) |
82 |
|
83 |
Yes, they are a security hazard and a PITA. Maybe I can sit it out |
84 |
until they come up with something better. |
85 |
|
86 |
>>>> With ZFS at hand, btrfs seems pretty obsolete. |
87 |
>>> |
88 |
>>> You do realize that btrfs was created when ZFS was already at hand, |
89 |
>>> right? I don't think that ZFS will be likely to make btrfs obsolete |
90 |
>>> unless it adopts more dynamic desktop-oriented features (like being |
91 |
>>> able to modify a vdev), and is relicensed to something GPL-compatible. |
92 |
>>> Unless those happen, it is unlikely that btrfs is going to go away, |
93 |
>>> unless it is replaced by something different. |
94 |
>> |
95 |
>> Let's say it seems /currently/ obsolete. |
96 |
> |
97 |
> You seem to have an interesting definition of "obsolete" - something |
98 |
> which holds potential promise for the future is better described as |
99 |
> "experimental." |
100 |
|
101 |
Can you build systems on potential promises for the future? |
102 |
|
103 |
If the resources it takes to develop btrfs would be put towards |
104 |
improving ZFS, or the other way round, wouldn't that be more efficient? |
105 |
We might even have a better solution available now. Of course, it's not |
106 |
a good idea to remove variety, so it's a dilemma. But are the features |
107 |
provided or intended to be provided and the problems both btrfs and ZFS |
108 |
are trying to solve so much different that that each of them needs to |
109 |
re-invent the wheel? |
110 |
|
111 |
>> Solutions are needed /now/, not in about 10 years when btrfs might be |
112 |
>> ready. |
113 |
>> |
114 |
> |
115 |
> Well, feel free to create one. Nobody is stopping anybody from using |
116 |
> zfs, but unless it is either relicensed by Oracle or the |
117 |
> kernel/grub/etc is relicensed by everybody else you're unlikely to see |
118 |
> it become a mainstream solution. That seems to be the biggest barrier |
119 |
> to adoption, though it would be nice for small installations if vdevs |
120 |
> were more dynamic. |
121 |
> |
122 |
> By all means use it if that is your preference. A license may seem |
123 |
> like a small thing, but entire desktop environments have been built as |
124 |
> a result of them. When a mainstream linux distro can't put ZFS |
125 |
> support on their installation CD due to licensing compatibility it |
126 |
> makes it pretty impractical to use it for your default filesystem. |
127 |
> |
128 |
> I'd love to see the bugs worked out of btrfs faster, but for what I've |
129 |
> paid for it so far I'd say I'm getting good value for my $0. It is |
130 |
> FOSS - it gets done when those contributing to it (whether paid or |
131 |
> not) are done. The ones who are paying for it get to decide for |
132 |
> themselves if it meets their needs, which could be quite different |
133 |
> from yours. |
134 |
|
135 |
What are these licensing issues good for other than preventing |
136 |
solutions? |
137 |
|
138 |
> I'd actually be interested in a comparison of the underlying btrfs vs |
139 |
> zfs designs. I'm not talking about implementation (bugs/etc), but the |
140 |
> fundamental designs. What features are possible to add to one which |
141 |
> are impossible to add to the other, what performance limitations will |
142 |
> the one always suffer in comparison to the other, etc? All the |
143 |
> comparisons I've seen just compare the implementations, which is |
144 |
> useful if you're trying to decide what to install /right now/ but less |
145 |
> so if you're trying to understand the likely future of either. |
146 |
|
147 |
The future is not predictable, and you can only install something |
148 |
/now/. What you will be able to install in the future and what your |
149 |
requirements are in the future isn't very relevant. |
150 |
|
151 |
In the future, you'll probably be basically in the same situation you're |
152 |
in now, i. e. you'll find the file systems widely used not exactly up to |
153 |
the requirements and "experimental" file systems that may make you ask |
154 |
what to install /then/ and what their future might be. |
155 |
|
156 |
So what's the benefit you'd get from the comparison you're interested |
157 |
in? |
158 |
|
159 |
|
160 |
-- |
161 |
Again we must be afraid of speaking of daemons for fear that daemons |
162 |
might swallow us. Finally, this fear has become reasonable. |