Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

option to choose tomb filesystem #45

Open
boyska opened this issue Aug 31, 2011 · 13 comments
Open

option to choose tomb filesystem #45

boyska opened this issue Aug 31, 2011 · 13 comments
Assignees
Labels
feat wish feature we wish someone would refine and implement

Comments

@boyska
Copy link
Contributor

boyska commented Aug 31, 2011

Sometimes fat32 can be better than ext3 (especially for moving the tomb on another computer). Sometimes it's the opposite (fat32 has a lot of limitations).

We should add an option --filesystem=FSNAME to the create subcommand, to let the user choose it.

EDIT: still requested XFS and FAT32

@jaromil
Copy link
Member

jaromil commented Jan 17, 2012

if we make it configurable, what's the best way to check which filesystem the tomb is formatted?
I mean, without mounting it?
this is needed for instance in case one calls resize on a non-EXT tomb, the command should refuse to function.

@davinerd
Copy link
Member

On 17/01/2012 18:09, Jaromil wrote:

if we make it configurable, what's the best way to check which filesystem the tomb is formatted?
I mean, without mounting it?
this is needed for instance in case one calls resize on a non-EXT tomb, the command should refuse to function.

Well, if we want to do some quick job, we can use sfdisk.
If we wanto to do some good (but hard) job, we must use hexdump (or xdd)
to check the offset byte partition and match with a predefined set of
'tomb supported filesystem'.

This will go togheter to #45 that I
want to code (I'll start it this weekend).

If we choose one of these approaches, I can code this into #45 and then
adding this feature to 'resize' command.

Anathema

+--------------------------------------------------------------------+
|GPG/PGP KeyID: 0F26965C available on http://pgpkeys.mit.edu:11371/ |
|Fingerprint: F808 18A2 2E7D 6E7A 7A18 4062 0AA3 7BF2 0F26 965C |
| |
|http://www.msack.org |
|https://tboxes.tracciabi.li/anathema
+--------------------------------------------------------------------+

@jaromil
Copy link
Member

jaromil commented Jan 12, 2014

Bumping this issue since I want to use ZFS now on some tombs. It features history and compression.

So I'll take it from here and hack something together soon. I think of a -t option (like with mount) on lock()

Tomb also needs to save information on how it was formatted, or even better detect (with sfdisk?)

Will try ASAP. So far I can see useful options for EXT2/3/4 and ZFS, not sure what else.
FAT is not looking like a sane option since Tomb works anyway only on Linux...

@boyska
Copy link
Contributor Author

boyska commented Jan 12, 2014

I find -t perfectly fine for specifying filesystem.
I don't think there's any need for saving this informations; linux
should autodetect how to mount filesystems.

I think FAT is great for most tombs, but that's another story :)

@jaromil
Copy link
Member

jaromil commented Jan 13, 2014

ZFS works in a very different way than other Linux filesystems, it needs to have ad-hoc code for its usage.

Why do you think FAT is great? can you sketch a situation where it would be useful?
If you want Windows and Apple computers to access the contents of a Tomb, what about sharing it via Samba?

@boyska
Copy link
Contributor Author

boyska commented Jan 13, 2014

On a computer, my UID is 1001. On another one, my UID is 1002.
Sharing a tomb between these two computers is a pain.
FAT would solve these problems.

@jaromil
Copy link
Member

jaromil commented Jan 13, 2014

Don't use FAT to solve such a problem. FAT will never make it in Tomb for such a reason, it is a complex way to solve a simple problem and implies huge drawbacks.

Besides, look at line 1511:

    chown ${_uid}:${_gid} ${tombmount}
    chmod 0750 ${tombmount}

why that is not working for you?

any other reason you like to put forward to advocate use of FAT?

@boyska
Copy link
Contributor Author

boyska commented Jan 13, 2014

any other reason you like to put forward to advocate use of FAT?

nope. That is the only one. I'll doublecheck the chown you pointed me

@hellekin
Copy link
Contributor

why that is not working for you?

Probably because it does not change the ownership of the files inside the Tomb.

Indeed, that's an interesting issue. I have it also. We could take advantage of the hooks to chown -R the contents to the UID that mounted the tomb, but I see two issues there: 1) all files might not share the same UID and GID inside the Tomb for specific reasons, and 2) the user mounting the Tomb might not have the right to perform that operation (even if sudo is available).

If the user gets to the point she needs to own the files, we can safely assume she is the right owner of the Tomb, so we could simply add chown -R ${_uid} ${tombmount} (leaving the GID unchanged for files inside the tomb).

@jaromil
Copy link
Member

jaromil commented Jan 13, 2014

ACK, true there is no -R in that chown I've pointed.

Hellekin analysis here is fairly complete.
about 1) yes, "specific reasons" come in mind, however I can't think of many real life cases where they are needed and in such cases such specific usage can be fixes with post-hooks. Enough to ignore the 1) issue I'd say.
about 2) if its tomb executing the chown... should be fine.

so the suggested solution of a chown -R of the ${_uid} alone is fine for me, but it should be specified in the documentation and bypassed by the -n option, together with the hooks.

@boyska
Copy link
Contributor Author

boyska commented Jan 14, 2014

I agree that the cases for multiple owner are not much; I can not say the same thing for the mode; therefore, I propose

chown -R ${_uid}:${_gid} ${tombmount}
chmod 0750 ${tombmount}

So that the chmod is not recursive

@hellekin
Copy link
Contributor

Hmmm no. The GID is often more significant than the uid, especially for giving read-only access to some applications, or other users. Please do not touch the GID :)

@cwmke
Copy link

cwmke commented Aug 10, 2015

I just want to toss one more fs onto the list. XFS if possible. Thanks for taking it into consideration.

@jaromil jaromil added the wish feature we wish someone would refine and implement label Nov 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat wish feature we wish someone would refine and implement
Projects
None yet
Development

No branches or pull requests

5 participants