[vminitd]: api for freeze/thaw filesystem operations

[saehejkang]

Addition of vminitd API for freeze/thaw filesystem operations

Closes#660

[jglogan]

@dcantah wdyt?

[dcantah]

Looks good!

[saehejkang]

Marking this ready for review as it is mainly feature complete.

---

@dcantah@jglogan

Is there a proper way to test these changes? I don't see any testing patterns for the vminitd api and I am sure there are some kinks that I need to fix.

[jglogan]

@saehejkang Congrats! And it's a good question.

I'm wondering if you could make a copy of one of the really simple "run container and exec a command" integration tests and extend it so that it does this instead:

• create an ext4 disk image file with a blank filesystem on it, defer its deletion
• run the container, with the disk image mounted to /data
• run a freeze operation
• exec an echo hello > /data/hello.txt
• copy (clone) the disk image file, defer its deletion
• run a thaw operation
• stop the container
• run another container, with the clone mounted to '/data'
• exec dmesg, ensure that the /data filesystem does not need fsck and mounted cleanly
• exec an ls /data, ensure that hello.txt does not exist
• stop the container

[dcantah]

You'll need to run make fmt here

[saehejkang]

@jglogan@dcantah ready for another review 🙏🏽

[jglogan]

@saehejkang looks good, only a couple of nits

[jglogan]

@saehejkang I ran into two errors when running make all integration:

• The defer-remove of cloneImageURL was removing the cloned image was removing the cloned image before it could be used in a later scope. Suite.swift removes testDir at the end of the tests, so the removes should be unnecessary.
• The dmesg check was failing; the output I was seeing when running the test was:

  [ 0.310796] EXT4-fs (vdc): warning: mounting unchecked fs, running e2fsck is recommended
  [ 0.310975] EXT4-fs (vdc): mounted filesystem 8a5c73a9-3c81-45b5-909f-d4708ebfa119 r/w without journal. Quota mode: disabled.
  

I think that the prior mount check should be sufficient to ensure that the cloned fs was able to be mounted. Here's what I changed to get tests to pass:

diff --git a/Sources/Integration/ContainerTests.swift b/Sources/Integration/ContainerTests.swift
index 81ffc09..60362c8 100644
--- a/Sources/Integration/ContainerTests.swift+++ b/Sources/Integration/ContainerTests.swift@@ -4256,10 +4256,6 @@ extension IntegrationSuite {
}
try FileManager.default.copyItem(at: diskImageURL, to: cloneImageURL)
- defer {- try? FileManager.default.removeItem(at: diskImageURL)- try? FileManager.default.removeItem(at: cloneImageURL)- }
try await writerContainer.filesystemOperation(operation: .thaw, path: "/data")
@@ -4304,22 +4300,6 @@ extension IntegrationSuite {
throw IntegrationError.assert(msg: "expected ext4 mount at /data, got: \(mountOutput)")
}
- let dmesgBuffer = BufferWriter()- let dmesgExec = try await verifyContainer.exec("verify-dmesg-clean") { config in- config.arguments = [- "/bin/sh", "-c",- "if dmesg | grep -Eiq 'fsck|recovering journal|recovery complete'; then dmesg | grep -Ei 'fsck|recovering journal|recovery complete'; exit 1; fi",- ]- config.stdout = dmesgBuffer- }- try await dmesgExec.start()- status = try await dmesgExec.wait()- try await dmesgExec.delete()- guard status.exitCode == 0 else {- let dmesgOutput = String(decoding: dmesgBuffer.data, as: UTF8.self)- throw IntegrationError.assert(msg: "dmesg indicates filesystem recovery on cloned image: \(dmesgOutput)")- }-
let lsBuffer = BufferWriter()
let lsExec = try await verifyContainer.exec("verify-no-hello") { config in
config.arguments = ["ls", "-1", "/data"]

[saehejkang]

Addition of vminitd API for freeze/thaw filesystem operations

Closes#660

[jglogan]

@dcantah wdyt?

[dcantah]

Looks good!

[saehejkang]

Marking this ready for review as it is mainly feature complete.

---

@dcantah@jglogan

Is there a proper way to test these changes? I don't see any testing patterns for the vminitd api and I am sure there are some kinks that I need to fix.

[jglogan]

@saehejkang Congrats! And it's a good question.

I'm wondering if you could make a copy of one of the really simple "run container and exec a command" integration tests and extend it so that it does this instead:

• create an ext4 disk image file with a blank filesystem on it, defer its deletion
• run the container, with the disk image mounted to /data
• run a freeze operation
• exec an echo hello > /data/hello.txt
• copy (clone) the disk image file, defer its deletion
• run a thaw operation
• stop the container
• run another container, with the clone mounted to '/data'
• exec dmesg, ensure that the /data filesystem does not need fsck and mounted cleanly
• exec an ls /data, ensure that hello.txt does not exist
• stop the container

[dcantah]

You'll need to run make fmt here

[saehejkang]

@jglogan@dcantah ready for another review 🙏🏽

[jglogan]

@saehejkang looks good, only a couple of nits

[jglogan]

@saehejkang I ran into two errors when running make all integration:

• The defer-remove of cloneImageURL was removing the cloned image was removing the cloned image before it could be used in a later scope. Suite.swift removes testDir at the end of the tests, so the removes should be unnecessary.
• The dmesg check was failing; the output I was seeing when running the test was:

  [ 0.310796] EXT4-fs (vdc): warning: mounting unchecked fs, running e2fsck is recommended
  [ 0.310975] EXT4-fs (vdc): mounted filesystem 8a5c73a9-3c81-45b5-909f-d4708ebfa119 r/w without journal. Quota mode: disabled.
  

I think that the prior mount check should be sufficient to ensure that the cloned fs was able to be mounted. Here's what I changed to get tests to pass:

diff --git a/Sources/Integration/ContainerTests.swift b/Sources/Integration/ContainerTests.swift
index 81ffc09..60362c8 100644
--- a/Sources/Integration/ContainerTests.swift+++ b/Sources/Integration/ContainerTests.swift@@ -4256,10 +4256,6 @@ extension IntegrationSuite {
}
try FileManager.default.copyItem(at: diskImageURL, to: cloneImageURL)
- defer {- try? FileManager.default.removeItem(at: diskImageURL)- try? FileManager.default.removeItem(at: cloneImageURL)- }
try await writerContainer.filesystemOperation(operation: .thaw, path: "/data")
@@ -4304,22 +4300,6 @@ extension IntegrationSuite {
throw IntegrationError.assert(msg: "expected ext4 mount at /data, got: \(mountOutput)")
}
- let dmesgBuffer = BufferWriter()- let dmesgExec = try await verifyContainer.exec("verify-dmesg-clean") { config in- config.arguments = [- "/bin/sh", "-c",- "if dmesg | grep -Eiq 'fsck|recovering journal|recovery complete'; then dmesg | grep -Ei 'fsck|recovering journal|recovery complete'; exit 1; fi",- ]- config.stdout = dmesgBuffer- }- try await dmesgExec.start()- status = try await dmesgExec.wait()- try await dmesgExec.delete()- guard status.exitCode == 0 else {- let dmesgOutput = String(decoding: dmesgBuffer.data, as: UTF8.self)- throw IntegrationError.assert(msg: "dmesg indicates filesystem recovery on cloned image: \(dmesgOutput)")- }-
let lsBuffer = BufferWriter()
let lsExec = try await verifyContainer.exec("verify-no-hello") { config in
config.arguments = ["ls", "-1", "/data"]

[saehejkang]

Addition of vminitd API for freeze/thaw filesystem operations

Closes#660

[jglogan]

@dcantah wdyt?

[dcantah]

Looks good!

[saehejkang]

Marking this ready for review as it is mainly feature complete.

---

@dcantah@jglogan

Is there a proper way to test these changes? I don't see any testing patterns for the vminitd api and I am sure there are some kinks that I need to fix.

[jglogan]

@saehejkang Congrats! And it's a good question.

I'm wondering if you could make a copy of one of the really simple "run container and exec a command" integration tests and extend it so that it does this instead:

• create an ext4 disk image file with a blank filesystem on it, defer its deletion
• run the container, with the disk image mounted to /data
• run a freeze operation
• exec an echo hello > /data/hello.txt
• copy (clone) the disk image file, defer its deletion
• run a thaw operation
• stop the container
• run another container, with the clone mounted to '/data'
• exec dmesg, ensure that the /data filesystem does not need fsck and mounted cleanly
• exec an ls /data, ensure that hello.txt does not exist
• stop the container

[dcantah]

You'll need to run make fmt here

[saehejkang]

@jglogan@dcantah ready for another review 🙏🏽

[jglogan]

@saehejkang looks good, only a couple of nits

[jglogan]

@saehejkang I ran into two errors when running make all integration:

• The defer-remove of cloneImageURL was removing the cloned image was removing the cloned image before it could be used in a later scope. Suite.swift removes testDir at the end of the tests, so the removes should be unnecessary.
• The dmesg check was failing; the output I was seeing when running the test was:

  [ 0.310796] EXT4-fs (vdc): warning: mounting unchecked fs, running e2fsck is recommended
  [ 0.310975] EXT4-fs (vdc): mounted filesystem 8a5c73a9-3c81-45b5-909f-d4708ebfa119 r/w without journal. Quota mode: disabled.
  

I think that the prior mount check should be sufficient to ensure that the cloned fs was able to be mounted. Here's what I changed to get tests to pass:

diff --git a/Sources/Integration/ContainerTests.swift b/Sources/Integration/ContainerTests.swift
index 81ffc09..60362c8 100644
--- a/Sources/Integration/ContainerTests.swift+++ b/Sources/Integration/ContainerTests.swift@@ -4256,10 +4256,6 @@ extension IntegrationSuite {
}
try FileManager.default.copyItem(at: diskImageURL, to: cloneImageURL)
- defer {- try? FileManager.default.removeItem(at: diskImageURL)- try? FileManager.default.removeItem(at: cloneImageURL)- }
try await writerContainer.filesystemOperation(operation: .thaw, path: "/data")
@@ -4304,22 +4300,6 @@ extension IntegrationSuite {
throw IntegrationError.assert(msg: "expected ext4 mount at /data, got: \(mountOutput)")
}
- let dmesgBuffer = BufferWriter()- let dmesgExec = try await verifyContainer.exec("verify-dmesg-clean") { config in- config.arguments = [- "/bin/sh", "-c",- "if dmesg | grep -Eiq 'fsck|recovering journal|recovery complete'; then dmesg | grep -Ei 'fsck|recovering journal|recovery complete'; exit 1; fi",- ]- config.stdout = dmesgBuffer- }- try await dmesgExec.start()- status = try await dmesgExec.wait()- try await dmesgExec.delete()- guard status.exitCode == 0 else {- let dmesgOutput = String(decoding: dmesgBuffer.data, as: UTF8.self)- throw IntegrationError.assert(msg: "dmesg indicates filesystem recovery on cloned image: \(dmesgOutput)")- }-
let lsBuffer = BufferWriter()
let lsExec = try await verifyContainer.exec("verify-no-hello") { config in
config.arguments = ["ls", "-1", "/data"]

[saehejkang]

Addition of vminitd API for freeze/thaw filesystem operations

Closes#660

[jglogan]

@dcantah wdyt?

[dcantah]

Looks good!

[saehejkang]

Marking this ready for review as it is mainly feature complete.

---

@dcantah@jglogan

Is there a proper way to test these changes? I don't see any testing patterns for the vminitd api and I am sure there are some kinks that I need to fix.

[jglogan]

@saehejkang Congrats! And it's a good question.

I'm wondering if you could make a copy of one of the really simple "run container and exec a command" integration tests and extend it so that it does this instead:

• create an ext4 disk image file with a blank filesystem on it, defer its deletion
• run the container, with the disk image mounted to /data
• run a freeze operation
• exec an echo hello > /data/hello.txt
• copy (clone) the disk image file, defer its deletion
• run a thaw operation
• stop the container
• run another container, with the clone mounted to '/data'
• exec dmesg, ensure that the /data filesystem does not need fsck and mounted cleanly
• exec an ls /data, ensure that hello.txt does not exist
• stop the container

[dcantah]

You'll need to run make fmt here

[saehejkang]

@jglogan@dcantah ready for another review 🙏🏽

[jglogan]

@saehejkang looks good, only a couple of nits

[jglogan]

@saehejkang I ran into two errors when running make all integration:

• The defer-remove of cloneImageURL was removing the cloned image was removing the cloned image before it could be used in a later scope. Suite.swift removes testDir at the end of the tests, so the removes should be unnecessary.
• The dmesg check was failing; the output I was seeing when running the test was:

  [ 0.310796] EXT4-fs (vdc): warning: mounting unchecked fs, running e2fsck is recommended
  [ 0.310975] EXT4-fs (vdc): mounted filesystem 8a5c73a9-3c81-45b5-909f-d4708ebfa119 r/w without journal. Quota mode: disabled.
  

I think that the prior mount check should be sufficient to ensure that the cloned fs was able to be mounted. Here's what I changed to get tests to pass:

diff --git a/Sources/Integration/ContainerTests.swift b/Sources/Integration/ContainerTests.swift
index 81ffc09..60362c8 100644
--- a/Sources/Integration/ContainerTests.swift+++ b/Sources/Integration/ContainerTests.swift@@ -4256,10 +4256,6 @@ extension IntegrationSuite {
}
try FileManager.default.copyItem(at: diskImageURL, to: cloneImageURL)
- defer {- try? FileManager.default.removeItem(at: diskImageURL)- try? FileManager.default.removeItem(at: cloneImageURL)- }
try await writerContainer.filesystemOperation(operation: .thaw, path: "/data")
@@ -4304,22 +4300,6 @@ extension IntegrationSuite {
throw IntegrationError.assert(msg: "expected ext4 mount at /data, got: \(mountOutput)")
}
- let dmesgBuffer = BufferWriter()- let dmesgExec = try await verifyContainer.exec("verify-dmesg-clean") { config in- config.arguments = [- "/bin/sh", "-c",- "if dmesg | grep -Eiq 'fsck|recovering journal|recovery complete'; then dmesg | grep -Ei 'fsck|recovering journal|recovery complete'; exit 1; fi",- ]- config.stdout = dmesgBuffer- }- try await dmesgExec.start()- status = try await dmesgExec.wait()- try await dmesgExec.delete()- guard status.exitCode == 0 else {- let dmesgOutput = String(decoding: dmesgBuffer.data, as: UTF8.self)- throw IntegrationError.assert(msg: "dmesg indicates filesystem recovery on cloned image: \(dmesgOutput)")- }-
let lsBuffer = BufferWriter()
let lsExec = try await verifyContainer.exec("verify-no-hello") { config in
config.arguments = ["ls", "-1", "/data"]

[saehejkang]

Addition of vminitd API for freeze/thaw filesystem operations

Closes#660

[jglogan]

@dcantah wdyt?

[dcantah]

Looks good!

[saehejkang]

Marking this ready for review as it is mainly feature complete.

---

@dcantah@jglogan

Is there a proper way to test these changes? I don't see any testing patterns for the vminitd api and I am sure there are some kinks that I need to fix.

[jglogan]

@saehejkang Congrats! And it's a good question.

I'm wondering if you could make a copy of one of the really simple "run container and exec a command" integration tests and extend it so that it does this instead:

• create an ext4 disk image file with a blank filesystem on it, defer its deletion
• run the container, with the disk image mounted to /data
• run a freeze operation
• exec an echo hello > /data/hello.txt
• copy (clone) the disk image file, defer its deletion
• run a thaw operation
• stop the container
• run another container, with the clone mounted to '/data'
• exec dmesg, ensure that the /data filesystem does not need fsck and mounted cleanly
• exec an ls /data, ensure that hello.txt does not exist
• stop the container

[dcantah]

You'll need to run make fmt here

[saehejkang]

@jglogan@dcantah ready for another review 🙏🏽

[jglogan]

@saehejkang looks good, only a couple of nits

[jglogan]

@saehejkang I ran into two errors when running make all integration:

• The defer-remove of cloneImageURL was removing the cloned image was removing the cloned image before it could be used in a later scope. Suite.swift removes testDir at the end of the tests, so the removes should be unnecessary.
• The dmesg check was failing; the output I was seeing when running the test was:

  [ 0.310796] EXT4-fs (vdc): warning: mounting unchecked fs, running e2fsck is recommended
  [ 0.310975] EXT4-fs (vdc): mounted filesystem 8a5c73a9-3c81-45b5-909f-d4708ebfa119 r/w without journal. Quota mode: disabled.
  

I think that the prior mount check should be sufficient to ensure that the cloned fs was able to be mounted. Here's what I changed to get tests to pass:

diff --git a/Sources/Integration/ContainerTests.swift b/Sources/Integration/ContainerTests.swift
index 81ffc09..60362c8 100644
--- a/Sources/Integration/ContainerTests.swift+++ b/Sources/Integration/ContainerTests.swift@@ -4256,10 +4256,6 @@ extension IntegrationSuite {
}
try FileManager.default.copyItem(at: diskImageURL, to: cloneImageURL)
- defer {- try? FileManager.default.removeItem(at: diskImageURL)- try? FileManager.default.removeItem(at: cloneImageURL)- }
try await writerContainer.filesystemOperation(operation: .thaw, path: "/data")
@@ -4304,22 +4300,6 @@ extension IntegrationSuite {
throw IntegrationError.assert(msg: "expected ext4 mount at /data, got: \(mountOutput)")
}
- let dmesgBuffer = BufferWriter()- let dmesgExec = try await verifyContainer.exec("verify-dmesg-clean") { config in- config.arguments = [- "/bin/sh", "-c",- "if dmesg | grep -Eiq 'fsck|recovering journal|recovery complete'; then dmesg | grep -Ei 'fsck|recovering journal|recovery complete'; exit 1; fi",- ]- config.stdout = dmesgBuffer- }- try await dmesgExec.start()- status = try await dmesgExec.wait()- try await dmesgExec.delete()- guard status.exitCode == 0 else {- let dmesgOutput = String(decoding: dmesgBuffer.data, as: UTF8.self)- throw IntegrationError.assert(msg: "dmesg indicates filesystem recovery on cloned image: \(dmesgOutput)")- }-
let lsBuffer = BufferWriter()
let lsExec = try await verifyContainer.exec("verify-no-hello") { config in
config.arguments = ["ls", "-1", "/data"]

[saehejkang]

Addition of vminitd API for freeze/thaw filesystem operations

Closes#660

[jglogan]

@dcantah wdyt?

[dcantah]

Looks good!

[saehejkang]

Marking this ready for review as it is mainly feature complete.

---

@dcantah@jglogan

Is there a proper way to test these changes? I don't see any testing patterns for the vminitd api and I am sure there are some kinks that I need to fix.

[jglogan]

@saehejkang Congrats! And it's a good question.

I'm wondering if you could make a copy of one of the really simple "run container and exec a command" integration tests and extend it so that it does this instead:

• create an ext4 disk image file with a blank filesystem on it, defer its deletion
• run the container, with the disk image mounted to /data
• run a freeze operation
• exec an echo hello > /data/hello.txt
• copy (clone) the disk image file, defer its deletion
• run a thaw operation
• stop the container
• run another container, with the clone mounted to '/data'
• exec dmesg, ensure that the /data filesystem does not need fsck and mounted cleanly
• exec an ls /data, ensure that hello.txt does not exist
• stop the container

[dcantah]

You'll need to run make fmt here

[saehejkang]

@jglogan@dcantah ready for another review 🙏🏽

[jglogan]

@saehejkang looks good, only a couple of nits

[jglogan]

@saehejkang I ran into two errors when running make all integration:

• The defer-remove of cloneImageURL was removing the cloned image was removing the cloned image before it could be used in a later scope. Suite.swift removes testDir at the end of the tests, so the removes should be unnecessary.
• The dmesg check was failing; the output I was seeing when running the test was:

  [ 0.310796] EXT4-fs (vdc): warning: mounting unchecked fs, running e2fsck is recommended
  [ 0.310975] EXT4-fs (vdc): mounted filesystem 8a5c73a9-3c81-45b5-909f-d4708ebfa119 r/w without journal. Quota mode: disabled.
  

I think that the prior mount check should be sufficient to ensure that the cloned fs was able to be mounted. Here's what I changed to get tests to pass:

diff --git a/Sources/Integration/ContainerTests.swift b/Sources/Integration/ContainerTests.swift
index 81ffc09..60362c8 100644
--- a/Sources/Integration/ContainerTests.swift+++ b/Sources/Integration/ContainerTests.swift@@ -4256,10 +4256,6 @@ extension IntegrationSuite {
}
try FileManager.default.copyItem(at: diskImageURL, to: cloneImageURL)
- defer {- try? FileManager.default.removeItem(at: diskImageURL)- try? FileManager.default.removeItem(at: cloneImageURL)- }
try await writerContainer.filesystemOperation(operation: .thaw, path: "/data")
@@ -4304,22 +4300,6 @@ extension IntegrationSuite {
throw IntegrationError.assert(msg: "expected ext4 mount at /data, got: \(mountOutput)")
}
- let dmesgBuffer = BufferWriter()- let dmesgExec = try await verifyContainer.exec("verify-dmesg-clean") { config in- config.arguments = [- "/bin/sh", "-c",- "if dmesg | grep -Eiq 'fsck|recovering journal|recovery complete'; then dmesg | grep -Ei 'fsck|recovering journal|recovery complete'; exit 1; fi",- ]- config.stdout = dmesgBuffer- }- try await dmesgExec.start()- status = try await dmesgExec.wait()- try await dmesgExec.delete()- guard status.exitCode == 0 else {- let dmesgOutput = String(decoding: dmesgBuffer.data, as: UTF8.self)- throw IntegrationError.assert(msg: "dmesg indicates filesystem recovery on cloned image: \(dmesgOutput)")- }-
let lsBuffer = BufferWriter()
let lsExec = try await verifyContainer.exec("verify-no-hello") { config in
config.arguments = ["ls", "-1", "/data"]

[saehejkang]

Addition of vminitd API for freeze/thaw filesystem operations

Closes#660

[jglogan]

@dcantah wdyt?

[dcantah]

Looks good!

[saehejkang]

Marking this ready for review as it is mainly feature complete.

---

@dcantah@jglogan

Is there a proper way to test these changes? I don't see any testing patterns for the vminitd api and I am sure there are some kinks that I need to fix.

[jglogan]

@saehejkang Congrats! And it's a good question.

I'm wondering if you could make a copy of one of the really simple "run container and exec a command" integration tests and extend it so that it does this instead:

• create an ext4 disk image file with a blank filesystem on it, defer its deletion
• run the container, with the disk image mounted to /data
• run a freeze operation
• exec an echo hello > /data/hello.txt
• copy (clone) the disk image file, defer its deletion
• run a thaw operation
• stop the container
• run another container, with the clone mounted to '/data'
• exec dmesg, ensure that the /data filesystem does not need fsck and mounted cleanly
• exec an ls /data, ensure that hello.txt does not exist
• stop the container

[dcantah]

You'll need to run make fmt here

[saehejkang]

@jglogan@dcantah ready for another review 🙏🏽

[jglogan]

@saehejkang looks good, only a couple of nits

[jglogan]

@saehejkang I ran into two errors when running make all integration:

• The defer-remove of cloneImageURL was removing the cloned image was removing the cloned image before it could be used in a later scope. Suite.swift removes testDir at the end of the tests, so the removes should be unnecessary.
• The dmesg check was failing; the output I was seeing when running the test was:

  [ 0.310796] EXT4-fs (vdc): warning: mounting unchecked fs, running e2fsck is recommended
  [ 0.310975] EXT4-fs (vdc): mounted filesystem 8a5c73a9-3c81-45b5-909f-d4708ebfa119 r/w without journal. Quota mode: disabled.
  

I think that the prior mount check should be sufficient to ensure that the cloned fs was able to be mounted. Here's what I changed to get tests to pass:

diff --git a/Sources/Integration/ContainerTests.swift b/Sources/Integration/ContainerTests.swift
index 81ffc09..60362c8 100644
--- a/Sources/Integration/ContainerTests.swift+++ b/Sources/Integration/ContainerTests.swift@@ -4256,10 +4256,6 @@ extension IntegrationSuite {
}
try FileManager.default.copyItem(at: diskImageURL, to: cloneImageURL)
- defer {- try? FileManager.default.removeItem(at: diskImageURL)- try? FileManager.default.removeItem(at: cloneImageURL)- }
try await writerContainer.filesystemOperation(operation: .thaw, path: "/data")
@@ -4304,22 +4300,6 @@ extension IntegrationSuite {
throw IntegrationError.assert(msg: "expected ext4 mount at /data, got: \(mountOutput)")
}
- let dmesgBuffer = BufferWriter()- let dmesgExec = try await verifyContainer.exec("verify-dmesg-clean") { config in- config.arguments = [- "/bin/sh", "-c",- "if dmesg | grep -Eiq 'fsck|recovering journal|recovery complete'; then dmesg | grep -Ei 'fsck|recovering journal|recovery complete'; exit 1; fi",- ]- config.stdout = dmesgBuffer- }- try await dmesgExec.start()- status = try await dmesgExec.wait()- try await dmesgExec.delete()- guard status.exitCode == 0 else {- let dmesgOutput = String(decoding: dmesgBuffer.data, as: UTF8.self)- throw IntegrationError.assert(msg: "dmesg indicates filesystem recovery on cloned image: \(dmesgOutput)")- }-
let lsBuffer = BufferWriter()
let lsExec = try await verifyContainer.exec("verify-no-hello") { config in
config.arguments = ["ls", "-1", "/data"]

[saehejkang]

Addition of vminitd API for freeze/thaw filesystem operations

Closes#660

[jglogan]

@dcantah wdyt?

[dcantah]

Looks good!

[saehejkang]

Marking this ready for review as it is mainly feature complete.

---

@dcantah@jglogan

Is there a proper way to test these changes? I don't see any testing patterns for the vminitd api and I am sure there are some kinks that I need to fix.

[jglogan]

@saehejkang Congrats! And it's a good question.

I'm wondering if you could make a copy of one of the really simple "run container and exec a command" integration tests and extend it so that it does this instead:

• create an ext4 disk image file with a blank filesystem on it, defer its deletion
• run the container, with the disk image mounted to /data
• run a freeze operation
• exec an echo hello > /data/hello.txt
• copy (clone) the disk image file, defer its deletion
• run a thaw operation
• stop the container
• run another container, with the clone mounted to '/data'
• exec dmesg, ensure that the /data filesystem does not need fsck and mounted cleanly
• exec an ls /data, ensure that hello.txt does not exist
• stop the container

[dcantah]

You'll need to run make fmt here

[saehejkang]

@jglogan@dcantah ready for another review 🙏🏽

[jglogan]

@saehejkang looks good, only a couple of nits

[jglogan]

@saehejkang I ran into two errors when running make all integration:

• The defer-remove of cloneImageURL was removing the cloned image was removing the cloned image before it could be used in a later scope. Suite.swift removes testDir at the end of the tests, so the removes should be unnecessary.
• The dmesg check was failing; the output I was seeing when running the test was:

  [ 0.310796] EXT4-fs (vdc): warning: mounting unchecked fs, running e2fsck is recommended
  [ 0.310975] EXT4-fs (vdc): mounted filesystem 8a5c73a9-3c81-45b5-909f-d4708ebfa119 r/w without journal. Quota mode: disabled.
  

I think that the prior mount check should be sufficient to ensure that the cloned fs was able to be mounted. Here's what I changed to get tests to pass:

diff --git a/Sources/Integration/ContainerTests.swift b/Sources/Integration/ContainerTests.swift
index 81ffc09..60362c8 100644
--- a/Sources/Integration/ContainerTests.swift+++ b/Sources/Integration/ContainerTests.swift@@ -4256,10 +4256,6 @@ extension IntegrationSuite {
}
try FileManager.default.copyItem(at: diskImageURL, to: cloneImageURL)
- defer {- try? FileManager.default.removeItem(at: diskImageURL)- try? FileManager.default.removeItem(at: cloneImageURL)- }
try await writerContainer.filesystemOperation(operation: .thaw, path: "/data")
@@ -4304,22 +4300,6 @@ extension IntegrationSuite {
throw IntegrationError.assert(msg: "expected ext4 mount at /data, got: \(mountOutput)")
}
- let dmesgBuffer = BufferWriter()- let dmesgExec = try await verifyContainer.exec("verify-dmesg-clean") { config in- config.arguments = [- "/bin/sh", "-c",- "if dmesg | grep -Eiq 'fsck|recovering journal|recovery complete'; then dmesg | grep -Ei 'fsck|recovering journal|recovery complete'; exit 1; fi",- ]- config.stdout = dmesgBuffer- }- try await dmesgExec.start()- status = try await dmesgExec.wait()- try await dmesgExec.delete()- guard status.exitCode == 0 else {- let dmesgOutput = String(decoding: dmesgBuffer.data, as: UTF8.self)- throw IntegrationError.assert(msg: "dmesg indicates filesystem recovery on cloned image: \(dmesgOutput)")- }-
let lsBuffer = BufferWriter()
let lsExec = try await verifyContainer.exec("verify-no-hello") { config in
config.arguments = ["ls", "-1", "/data"]